Change an existing C source file to 80 column width in Vim - vim

I have several C files, in which the lines exceed more than 80 columns. I need to wrap them to a 80 column boundary and at the same time maintain proper C syntax. Is this possible in Vim?
I have seen several solutions on the web for doing it on a normal text file. Also, have found tricks to do wrapping in a C file, which is about to be edited. But not for existing C files.
Any tools for achieving this apart from Vim are also welcome.

If you edit c-sources it is likely that you set the cindent option. Unfortunately the textwidth option doesn't work with cindent.
For your purpose artistic style, although it's a very nice program isn't recommended either since it doesn't support the breaking of long lines.
To get what you want i use gnu indent and set equalprg to
let &equalprg= "indent -l80 -i" . &shiftwidth . " <optional args>"
and add
map <leader>i mzgg=G`z
to my ~/.vimrc. With that pressing <leader>i reformats the whole file without changing the cursor's position.
Another possibility would be to add an autocommand that indents the source on every write, like
autocmd BufWrite *.c execute "%!".&equalprg

With vim you could do that with :set tw=79 and gggqG. However, it is not context-aware so you will need to restore certain lines (for example, lines with long strings in them).
For an external tool you might want to look at Artistic Style, which reformat lines where reformatting is not hard (for example, lines containing a {).

Related

Vim doesn't use tabstop distance in insert-mode

I'm having problems with auto indentation in vim while programming in lisp.
My .vimrc had the following settings for tabs:
set noexpandtab
set autoindent
set softtabstop=0
set shiftwidth=8
set tabstop=8
When I type (if <enter> in insert-mode, a new line is created with an indentation of two spaces.
None of my settings say anything about two spaces, so why don't I get a tab?
What setting can I use to change the indentation while in insert-mode?
Thanks in advance!
Update:
Thanks for the answers, the settings are not overwritten.
It has to do with the "default lisp indenting".
In the :help lisp it says something about changing the p flag in
cpoptions. This is what it says in the help for the cpoptions flags:
p - Vi compatible Lisp indenting. When not present, a slightly better algorithm is used.
Setting it does change the indent to one space instead of two spaces.
Still not sure how to change this to something else though.
Looks like this is two-space indentation is a hard coded behavior of :set lisp mode which ignores shiftwidth.
We can trace this to the source code which contains a hard-coded amount += 2; increment statement.
It's that way for a good reason; it has come to be the predominant way of writing Lisp.
As I wrote this answer, I peeked at samples of source code the following projects (all Lisp or Lisp-like languages):
Steel Bank Common Lisp (SBCL);
Clozure Common Lisp (CCL);
GNU Emacs;
Clojure;
GNU Guile;
Racket;
and GNU CLISP.
I did not spot a single example of anything but two-space indentation! With two-space indentation, you are in good/large company. You might as well get used to that; even if you somehow get Vim to follow your way, if you upstream anything into anyone's Lisp project, you will likely have to reformat.
Now, I have seen Lisp code using four-space indentation, like in very old code bases and some books.
By the way, sometimes you see if indented like this:
(if (condition)
(then)
(else))
This may happen where indentation is four spaces, but I'm referring situations when this is alignment, and not four space indentation. This formatting is, of course, standard for function arguments, but controversial for operators such as if. Some people like it that way in their code bases. For instance, this institution's randomly found coding style guide recommends this way of writing if, while also recommending two-space indentation.
Vim will do the above if you remove if from lispwords.
The :set lispwords=... parameter contains a comma-separated list of identifiers which follow operator-like indentation, meaning two spaces rather than function-like alignment: second and third lines align with argument. By default, if is found in lispwords.
Lisp mode also applies two space indentation to a function (i.e. form not listed in lispwords, if there is no argument):
(gobbledygook 1 2
2 3)
(gobbledygook
1)
That's also "canonical". Sometimes this comes in handy if you're trying to conform to some maximum line length; a function call running past the limit can sometimes be made to fit by moving all its arguments down, and just giving them two space indentation.
Each filetype can have its own settings in vim. So your .vimrc values can be overwritten in filetype plugins. To learn the current values of the settings for lisp filetype open the lisp file and run the following commands in vim command line:
:set noexpandtab?
:set autoindent?
:set softtabstop?
:set shiftwidth?
:set tabstop?
If they are different from the ones in .vimrc, then your values are overwritten in some plugin.
In order to overwrite them again with your custom values, create the ~/.vim/after/ftplugin/lisp.vim file with the required values:
set noexpandtab
set autoindent
set softtabstop=0
set shiftwidth=8
set tabstop=8

What's wrong with gVim copy paste between windows?

I'm new to vim and I'm using gVim on Windows. I have two windows open in the same gvim instance and I'm just trying to copy some code from one to another. For some reason when it pastes it replaces the contents of some code with literally this:
list.forEach(function(name){...}------------------------------------------
Obviously, my real code does not have ... or a ton of dashes. What the hell is happening?
The dashes (----------) give it away: The block of code has been folded. (You probably also see the line with different colors (depending on your colorscheme).) Depending on the filetype, folding can be manual or automatic. For your (JavaScript?) code, it's the latter. So when you paste a block of code, Vim automatically detects the block and folds it.
There's a whole lot of commands and options around folding. Read more about it at :help folding. If you find this too confusing (for now), turn it off via
:set nofoldenable
Just press zo on the dashes(-----)
Aside: Use zf on selected (v) lines to fold lines.
zo - Open
zo - Fold

Automatically Break/Merge Lines in Vim

I'm creating a document in latex and I would like all lines to be broken at roughly 80 characters. This is easy to do manually when writing new text, but the editing of old text often leads to lines that are longer or shorter. Fixing it leads to other lines that need to be changed and so on.
Is there an automatic way in vim to break lines after 80 characters and merge them if possible?
To make lines be only 80 characters long you can use textwidth
Assuming your latex file has the extension .tex you can add the following line to your vimrc
autocmd BufReadPost *.tex setlocal textwidth=80
To format the current paragraph you can use gqap
I use the following setup.
set textwidth=80
(either manually or in your ~/.vimrc). Then if I have a block of text in a file that I want to format I first mark it in visual mode (i.e., shift-V to switch to visual line mode and than mark all the lines you want to format) and then use gq. See also :help gq.

How do I avoid cumulative filetype commands in vim?

Let's say I load up a python file in vim. A quick check of :scriptnames shows that my ~/.vim/ftplugin/python/python.vim file loads as expected. One of the commands in this file highlights all characters that are past the 80th column. Now lets say I open a C++ file in another buffer (therefore running ~/.vim/ftplugin/cpp/cpp.vim). Although the new commands are executed, the settings in python.vim still apply; therefore characters are highlighted past the 80th column in my C++ file.
Is there anyway to make filetype commands not cumulative like this? I have filetype plugin indent on in my .vimrc.
The problem is that both 'colorcolumn' and :match (you didn't specify whether you use the new setting or the older highlight approach) are local to the window, but ftplugins should only set buffer-local settings.
Why are these settings window-local? That allows you to have the same buffer displayed in two windows, one with, and one without the highlighting.
What can you do to prevent this?
a) Don't set this in the ftplugin, and instead use mappings to toggle the colorcolumn on/off.
b) Put :setlocal nocolorcolumn into all ftplugin scripts (e.g. in ~/.vim/after/ftplugin/*.vim) for all filetypes that you're using. This will only work unless you switch between different filetypes in the same window.
c) The correct (but most complex) way to solve this is through a couple of :autocmds on BufWinEnter, BufWinLeave, and WinLeave events.

How to prevent Vim indenting wrapped text in parentheses

This has bugged me for a long time, and try as I might I can't find a way round it.
When I'm editing text (specifically latex, but that doesn't matter) files, I want it to auto-wrap at 80 columns. It does this, except if I happen to be in the middle of a parenthetical clause, it indents the text which is very annoying. For example, this works fine
Here is some text... over
two lines.
but this doesn't
Here is some text... (over
two
lines
If anyone can tell me how to turn this off (just for text/latex files) I'd be really grateful. Presumably it has something to do with the fact that this is desired behaviour in C, but I still can't figure out what's wrong.
:set nocindent
The other options do nothing, and the filetype detection doesn't change it.
There are three options you may need to turn off: set noai, set nosi, and setnocin (autoindent, smartindent, and cindent).
This may be related, when pasting from gui into terminal window, vim cannot distinguish paste modes, so to stop any odd things from occuring:
set paste
then paste text
set nopaste
I had similar issues trying to paste xml text, it would just keep indenting. :)
gvim, the gui version of vim, can detect paste modes.
You can have a look at the autoindent option :
autoindent - ai
Copy indent from current line when starting a new line (typing
in Insert mode or when using the "o" or "O" command). If you do not
type anything on the new line except and then type or
, the indent is deleted again. When autoindent is on,
formatting (with the "gq" command or when you reach 'textwidth' in
Insert mode) uses the indentation of the first line. When
'smartindent' or 'cindent' is on the indent is changed in specific
cases. The 'autoindent' option is reset when the 'paste' option is
set. {small difference from Vi: After the indent is deleted when
typing or , the cursor position when moving up or down is
after the deleted indent; Vi puts the cursor somewhere in the deleted
indent}.
From the official Vim documentation
filetype plugin indent on
This switches on three very clever
mechanisms:
Filetype detection. Whenever you start editing a file, Vim will try to
figure out what kind of file this
is. When you edit "main.c", Vim will
see the ".c" extension and
recognize this as a "c" filetype.
When you edit a file that starts with
"#!/bin/sh", Vim will recognize it as
a "sh" filetype. The filetype
detection is used for syntax
highlighting and the other two
items below. See |filetypes|.
Using filetype plugin files Many different filetypes are edited with
different options. For example,
when you edit a "c" file, it's very
useful to set the 'cindent' option to
automatically indent the lines. These
commonly useful option settings are
included with Vim in filetype plugins.
You can also add your own, see
|write-filetype-plugin|.
Using indent files When editing programs, the indent of a line can
often be computed automatically.
Vim comes with these indent rules for
a number of filetypes. See
|:filetype-indent-on| and
'indentexpr'.
:set noai
sets no auto indent tt may be smartindent though. Check out the doc and see if you can find something more
http://www.vim.org/htmldoc/indent.html

Resources