summaryrefslogtreecommitdiff
path: root/runtime/doc/usr_30.txt
diff options
context:
space:
mode:
authorBram Moolenaar <Bram@vim.org>2004-06-13 20:20:40 +0000
committerBram Moolenaar <Bram@vim.org>2004-06-13 20:20:40 +0000
commit071d4279d6ab81b7187b48f3a0fc61e587b6db6c (patch)
tree221cbe3c40e043163c06f61c52a7ba2eb41e12ce /runtime/doc/usr_30.txt
parentb4210b3bc14e2918f153a7307530fbe6eba659e1 (diff)
downloadvim-071d4279d6ab81b7187b48f3a0fc61e587b6db6c.zip
updated for version 7.0001
Diffstat (limited to 'runtime/doc/usr_30.txt')
-rw-r--r--runtime/doc/usr_30.txt643
1 files changed, 643 insertions, 0 deletions
diff --git a/runtime/doc/usr_30.txt b/runtime/doc/usr_30.txt
new file mode 100644
index 000000000..c88f060fa
--- /dev/null
+++ b/runtime/doc/usr_30.txt
@@ -0,0 +1,643 @@
+*usr_30.txt* For Vim version 7.0aa. Last change: 2004 Jan 17
+
+ VIM USER MANUAL - by Bram Moolenaar
+
+ Editing programs
+
+
+Vim has various commands that aid in writing computer programs. Compile a
+program and directly jump to reported errors. Automatically set the indent
+for many languages and format comments.
+
+|30.1| Compiling
+|30.2| Indenting C files
+|30.3| Automatic indenting
+|30.4| Other indenting
+|30.5| Tabs and spaces
+|30.6| Formatting comments
+
+ Next chapter: |usr_31.txt| Exploiting the GUI
+ Previous chapter: |usr_29.txt| Moving through programs
+Table of contents: |usr_toc.txt|
+
+==============================================================================
+*30.1* Compiling
+
+Vim has a set of so called "quickfix" commands. They enable you to compile a
+program from within Vim and then go through the errors generated and fix them
+(hopefully). You can then recompile and fix any new errors that are found
+until finally your program compiles without any error.
+
+The following command runs the program "make" (supplying it with any argument
+you give) and captures the results: >
+
+ :make {arguments}
+
+If errors were generated, they are captured and the editor positions you where
+the first error occurred.
+ Take a look at an example ":make" session. (Typical :make sessions generate
+far more errors and fewer stupid ones.) After typing ":make" the screen looks
+like this:
+
+ :!make | &tee /tmp/vim215953.err ~
+ gcc -g -Wall -o prog main.c sub.c ~
+ main.c: In function 'main': ~
+ main.c:6: too many arguments to function 'do_sub' ~
+ main.c: At top level: ~
+ main.c:10: parse error before '}' ~
+ make: *** [prog] Error 1 ~
+
+ 2 returned ~
+ "main.c" 11L, 111C ~
+ (3 of 6): too many arguments to function 'do_sub' ~
+ Hit ENTER or type command to continue ~
+
+From this you can see that you have errors in the file "main.c". When you
+press <Enter>, Vim displays the file "main.c", with the cursor positioned on
+line 6, the first line with an error. You did not need to specify the file or
+the line number, Vim knew where to go by looking in the error messages.
+
+ +---------------------------------------------------+
+ |int main() |
+ |{ |
+ | int i=3; |
+ cursor -> | do_sub("foo"); |
+ | ++i; |
+ | return (0); |
+ |} |
+ |} |
+ | ~ |
+ |(3 of 12): too many arguments to function 'do_sub' |
+ +---------------------------------------------------+
+
+The following command goes to where the next error occurs: >
+
+ :cnext
+
+Vim jumps to line 10, the last line in the file, where there is an extra '}'.
+ When there is not enough room, Vim will shorten the error message. To see
+the whole message use: >
+
+ :cc
+
+You can get an overview of all the error messages with the ":clist" command.
+The output looks like this: >
+
+ :clist
+< 3 main.c: 6:too many arguments to function 'do_sub' ~
+ 5 main.c: 10:parse error before '}' ~
+
+Only the lines where Vim recognized a file name and line number are listed
+here. It assumes those are the interesting lines and the rest is just boring
+messages. However, sometimes unrecognized lines do contain something you want
+to see. Output from the linker, for example, about an undefined function.
+To see all the messages add a "!" to the command: >
+
+ :clist!
+< 1 gcc -g -Wall -o prog main.c sub.c ~
+ 2 main.c: In function 'main': ~
+ 3 main.c:6: too many arguments to function 'do_sub' ~
+ 4 main.c: At top level: ~
+ 5 main.c:10: parse error before '}' ~
+ 6 make: *** [prog] Error 1 ~
+
+Vim will highlight the current error. To go back to the previous error, use:
+>
+ :cprevious
+
+Other commands to move around in the error list:
+
+ :cfirst to first error
+ :clast to last error
+ :cc 3 to error nr 3
+
+
+USING ANOTHER COMPILER
+
+The name of the program to run when the ":make" command is executed is defined
+by the 'makeprg' option. Usually this is set to "make", but Visual C++ users
+should set this to "nmake" by executing the following command: >
+
+ :set makeprg=nmake
+
+You can also include arguments in this option. Special characters need to
+be escaped with a backslash. Example: >
+
+ :set makeprg=nmake\ -f\ project.mak
+
+You can include special Vim keywords in the command specification. The %
+character expands to the name of the current file. So if you execute the
+command: >
+ :set makeprg=make\ %
+
+When you are editing main.c, then ":make" executes the following command: >
+
+ make main.c
+
+This is not too useful, so you will refine the command a little and use the :r
+(root) modifier: >
+
+ :set makeprg=make\ %:r.o
+
+Now the command executed is as follows: >
+
+ make main.o
+
+More about these modifiers here: |filename-modifiers|.
+
+
+OLD ERROR LISTS
+
+Suppose you ":make" a program. There is an warning message in one file and an
+error message in another. You fix the error and use ":make" again to check if
+it was really fixed. Now you want to look at the warning message. It doesn't
+show up in the last error list, since the file with the warning wasn't
+compiled again. You can go back to the previous error list with: >
+
+ :colder
+
+Then use ":clist" and ":cc {nr}" to jump to the place with the warning.
+ To go forward to the next error list: >
+
+ :cnewer
+
+Vim remembers ten error lists.
+
+
+SWITCHING COMPILERS
+
+You have to tell Vim what format the error messages are that your compiler
+produces. This is done with the 'errorformat' option. The syntax of this
+option is quite complicated and it can be made to fit almost any compiler.
+You can find the explanation here: |errorformat|.
+
+You might be using various different compilers. Setting the 'makeprg' option,
+and especially the 'errorformat' each time is not easy. Vim offers a simple
+method for this. For example, to switch to using the Microsoft Visual C++
+compiler: >
+
+ :compiler msvc
+
+This will find the Vim script for the "msvc" compiler and set the appropriate
+options.
+ You can write your own compiler files. See |write-compiler-plugin|.
+
+
+OUTPUT REDIRECTION
+
+The ":make" command redirects the output of the executed program to an error
+file. How this works depends on various things, such as the 'shell'. If your
+":make" command doesn't capture the output, check the 'makeef' and
+'shellpipe' options. The 'shellquote' and 'shellxquote' options might also
+matter.
+
+In case you can't get ":make" to redirect the file for you, an alternative is
+to compile the program in another window and redirect the output into a file.
+Then have Vim read this file with: >
+
+ :cfile {filename}
+
+Jumping to errors will work like with the ":make" command.
+
+==============================================================================
+*30.2* Indenting C files
+
+A program is much easier to understand when the lines have been properly
+indented. Vim offers various ways to make this less work.
+ For C programs set the 'cindent' option. Vim knows a lot about C programs
+and will try very hard to automatically set the indent for you. Set the
+'shiftwidth' option to the amount of spaces you want for a deeper level. Four
+spaces will work fine. One ":set" command will do it: >
+
+ :set cindent shiftwidth=4
+
+With this option enabled, when you type something such as "if (x)", the next
+line will automatically be indented an additional level.
+
+ if (flag)
+ Automatic indent ---> do_the_work();
+ Automatic unindent <-- if (other_flag) {
+ Automatic indent ---> do_file();
+ keep indent do_some_more();
+ Automatic unindent <-- }
+
+When you type something in curly braces ({}), the text will be indented at the
+start and unindented at the end. The unindenting will happen after typing the
+'}', since Vim can't guess what you are going to type.
+
+One side effect of automatic indentation is that it helps you catch errors in
+your code early. When you type a } to finish a function, only to find that
+the automatic indentation gives it more indent than what you expected, there
+is probably a } missing. Use the "%" command to find out which { matches the
+} you typed.
+ A missing ) and ; also cause extra indent. Thus if you get more white
+space than you would expect, check the preceding lines.
+
+When you have code that is badly formatted, or you inserted and deleted lines,
+you need to re-indent the lines. The "=" operator does this. The simplest
+form is: >
+
+ ==
+
+This indents the current line. Like with all operators, there are three ways
+to use it. In Visual mode "=" indents the selected lines. A useful text
+object is "a{". This selects the current {} block. Thus, to re-indent the
+code code block the cursor is in: >
+
+ =a{
+
+I you have really badly indented code, you can re-indent the whole file with:
+>
+ gg=G
+
+However, don't do this in files that have been carefully indented manually.
+The automatic indenting does a good job, but in some situations you might want
+to overrule it.
+
+
+SETTING INDENT STYLE
+
+Different people have different styles of indentation. By default Vim does a
+pretty good job of indenting in a way that 90% of programmers do. There are
+different styles, however; so if you want to, you can customize the
+indentation style with the 'cinoptions' option.
+ By default 'cinoptions' is empty and Vim uses the default style. You can
+add various items where you want something different. For example, to make
+curly braces be placed like this:
+
+ if (flag) ~
+ { ~
+ i = 8; ~
+ j = 0; ~
+ } ~
+
+Use this command: >
+
+ :set cinoptions+={2
+
+There are many of these items. See |cinoptions-values|.
+
+==============================================================================
+*30.3* Automatic indenting
+
+You don't want to switch on the 'cindent' option manually every time you edit
+a C file. This is how you make it work automatically: >
+
+ :filetype indent on
+
+Actually, this does a lot more than switching on 'cindent' for C files. First
+of all, it enables detecting the type of a file. That's the same as what is
+used for syntax highlighting.
+ When the filetype is known, Vim will search for an indent file for this
+type of file. The Vim distribution includes a number of these for various
+programming languages. This indent file will then prepare for automatic
+indenting specifically for this file.
+
+If you don't like the automatic indenting, you can switch it off again: >
+
+ :filetype indent off
+
+If you don't like the indenting for one specific type of file, this is how you
+avoid it. Create a file with just this one line: >
+
+ :let b:did_indent = 1
+
+Now you need to write this in a file with a specific name:
+
+ {directory}/indent/{filetype}.vim
+
+The {filetype} is the name of the file type, such as "cpp" or "java". You can
+see the exact name that Vim detected with this command: >
+
+ :set filetype
+
+In this file the output is:
+
+ filetype=help ~
+
+This you would use "help" for {filetype}.
+ For the {directory} part you need to use your runtime directory. Look at
+the output of this command: >
+
+ set runtimepath
+
+Now use the first item, the name before the first comma. Thus if the output
+looks like this:
+
+ runtimepath=~/.vim,/usr/local/share/vim/vim60/runtime,~/.vim/after ~
+
+You use "~/.vim" for {directory}. Then the resulting file name is:
+
+ ~/.vim/indent/help.vim ~
+
+Instead of switching the indenting off, you could write your own indent file.
+How to do that is explained here: |indent-expression|.
+
+==============================================================================
+*30.4* Other indenting
+
+The most simple form of automatic indenting is with the 'autoindent' option.
+It uses the indent from the previous line. A bit smarter is the 'smartindent'
+option. This is useful for languages where no indent file is available.
+'smartindent'is not as smart as 'cindent', but smarter than 'autoindent'.
+ With 'smartindent' set, an extra level of indentation is added for each {
+and removed for each }. An extra level of indentation will also be added for
+any of the words in the 'cinwords' option. Lines that begin with # are
+treated specially: all indentation is removed. This is done so that
+preprocessor directives will all start in column 1. The indentation is
+restored for the next line.
+
+
+CORRECTING INDENTS
+
+When you are using 'autoindent' or 'smartindent' to get the indent of the
+previous line, there will be many times when you need to add or remove one
+'shiftwidth' worth of indent. A quick way to do this is using the CTRL-D and
+CTRL-T commands in Insert mode.
+ For example, you are typing a shell script that is supposed to look like
+this:
+
+ if test -n a; then ~
+ echo a ~
+ echo "-------" ~
+ fi ~
+
+Start off by setting these option: >
+
+ :set autoindent shiftwidth=3
+
+You start by typing the first line, <Enter> and the start of the second line:
+
+ if test -n a; then ~
+ echo ~
+
+Now you see that you need an extra indent. Type CTRL-T. The result:
+
+ if test -n a; then ~
+ echo ~
+
+The CTRL-T command, in Insert mode, adds one 'shiftwidth' to the indent, no
+matter where in the line you are.
+ You continue typing the second line, <Enter> and the third line. This time
+the indent is OK. Then <Enter> and the last line. Now you have this:
+
+ if test -n a; then ~
+ echo a ~
+ echo "-------" ~
+ fi ~
+
+To remove the superfluous indent in the last line press CTRL-D. This deletes
+one 'shiftwidth' worth of indent, no matter where you are in the line.
+ When you are in Normal mode, you can use the ">>" and "<<" commands to
+shift lines. ">" and "<" are operators, thus you have the usual three ways to
+specify the lines you want to indent. A useful combination is: >
+
+ >i{
+
+This adds one indent to the current block of lines, inside {}. The { and }
+lines themselves are left unmodified. ">a{" includes them. In this example
+the cursor is on "printf":
+
+ original text after ">i{" after ">a{"
+
+ if (flag) if (flag) if (flag) ~
+ { { { ~
+ printf("yes"); printf("yes"); printf("yes"); ~
+ flag = 0; flag = 0; flag = 0; ~
+ } } } ~
+
+==============================================================================
+*30.5* Tabs and spaces
+
+'tabstop' is set to eight by default. Although you can change it, you quickly
+run into trouble later. Other programs won't know what tabstop value you
+used. They probably use the default value of eight, and your text suddenly
+looks very different. Also, most printers use a fixed tabstop value of eight.
+Thus it's best to keep 'tabstop' alone. (If you edit a file which was written
+with a different tabstop setting, see |25.3| for how to fix that.)
+ For indenting lines in a program, using a multiple of eight spaces makes
+you quickly run into the right border of the window. Using a single space
+doesn't provide enough visual difference. Many people prefer to use four
+spaces, a good compromise.
+ Since a <Tab> is eight spaces and you want to use an indent of four spaces,
+you can't use a <Tab> character to make your indent. There are two ways to
+handle this:
+
+1. Use a mix of <Tab> and space characters. Since a <Tab> takes the place of
+ eight spaces, you have fewer characters in your file. Inserting a <Tab>
+ is quicker than eight spaces. Backspacing works faster as well.
+
+2. Use spaces only. This avoids the trouble with programs that use a
+ different tabstop value.
+
+Fortunately, Vim supports both methods quite well.
+
+
+SPACES AND TABS
+
+If you are using a combination of tabs and spaces, you just edit normally.
+The Vim defaults do a fine job of handling things.
+ You can make life a little easier by setting the 'softtabstop' option.
+This option tells Vim to make the <Tab> key look and feel as if tabs were set
+at the value of 'softtabstop', but actually use a combination of tabs and
+spaces.
+ After you execute the following command, every time you press the <Tab> key
+the cursor moves to the next 4-column boundary: >
+
+ :set softtabstop=4
+
+When you start in the first column and press <Tab>, you get 4 spaces inserted
+in your text. The second time, Vim takes out the 4 spaces and puts in a <Tab>
+(thus taking you to column 8). Thus Vim uses as many <Tab>s as possible, and
+then fills up with spaces.
+ When backspacing it works the other way around. A <BS> will always delete
+the amount specified with 'softtabstop'. Then <Tabs> are used as many as
+possible and spaces to fill the gap.
+ The following shows what happens pressing <Tab> a few times, and then using
+<BS>. A "." stands for a space and "------->" for a <Tab>.
+
+ type result ~
+ <Tab> ....
+ <Tab><Tab> ------->
+ <Tab><Tab><Tab> ------->....
+ <Tab><Tab><Tab><BS> ------->
+ <Tab><Tab><Tab><BS><BS> ....
+
+An alternative is to use the 'smarttab' option. When it's set, Vim uses
+'shiftwidth' for a <Tab> typed in the indent of a line, and a real <Tab> when
+typed after the first non-blank character. However, <BS> doesn't work like
+with 'softtabstop'.
+
+
+JUST SPACES
+
+If you want absolutely no tabs in your file, you can set the 'expandtab'
+option: >
+
+ :set expandtab
+
+When this option is set, the <Tab> key inserts a series of spaces. Thus you
+get the same amount of white space as if a <Tab> character was inserted, but
+there isn't a real <Tab> character in your file.
+ The backspace key will delete each space by itself. Thus after typing one
+<Tab> you have to press the <BS> key up to eight times to undo it. If you are
+in the indent, pressing CTRL-D will be a lot quicker.
+
+
+CHANGING TABS IN SPACES (AND BACK)
+
+Setting 'expandtab' does not affect any existing tabs. In other words, any
+tabs in the document remain tabs. If you want to convert tabs to spaces, use
+the ":retab" command. Use these commands: >
+
+ :set expandtab
+ :%retab
+
+Now Vim will have changed all indents to use spaces instead of tabs. However,
+all tabs that come after a non-blank character are kept. If you want these to
+be converted as well, add a !: >
+
+ :%retab!
+
+This is a little bit dangerous, because it can also change tabs inside a
+string. To check if these exist, you could use this: >
+
+ /"[^"\t]*\t[^"]*"
+
+It's recommended not to use hard tabs inside a string. Replace them with
+"\t" to avoid trouble.
+
+The other way around works just as well: >
+
+ :set noexpandtab
+ :%retab!
+
+==============================================================================
+*30.6* Formatting comments
+
+One of the great things about Vim is that it understands comments. You can
+ask Vim to format a comment and it will do the right thing.
+ Suppose, for example, that you have the following comment:
+
+ /* ~
+ * This is a test ~
+ * of the text formatting. ~
+ */ ~
+
+You then ask Vim to format it by positioning the cursor at the start of the
+comment and type: >
+
+ gq]/
+
+"gq" is the operator to format text. "]/" is the motion that takes you to the
+end of a comment. The result is:
+
+ /* ~
+ * This is a test of the text formatting. ~
+ */ ~
+
+Notice that Vim properly handled the beginning of each line.
+ An alternative is to select the text that is to be formatted in Visual mode
+and type "gq".
+
+To add a new line to the comment, position the cursor on the middle line and
+press "o". The result looks like this:
+
+ /* ~
+ * This is a test of the text formatting. ~
+ * ~
+ */ ~
+
+Vim has automatically inserted a star and a space for you. Now you can type
+the comment text. When it gets longer than 'textwidth', Vim will break the
+line. Again, the star is inserted automatically:
+
+ /* ~
+ * This is a test of the text formatting. ~
+ * Typing a lot of text here will make Vim ~
+ * break ~
+ */ ~
+
+For this to work some flags must be present in 'formatoptions':
+
+ r insert the star when typing <Enter> in Insert mode
+ o insert the star when using "o" or "O" in Normal mode
+ c break comment text according to 'textwidth'
+
+See |fo-table| for more flags.
+
+
+DEFINING A COMMENT
+
+The 'comments' option defines what a comment looks like. Vim distinguishes
+between a single-line comment and a comment that has a different start, end
+and middle part.
+ Many single-line comments start with a specific character. In C++ // is
+used, in Makefiles #, in Vim scripts ". For example, to make Vim understand
+C++ comments: >
+
+ :set comments=://
+
+The colon separates the flags of an item from the text by which the comment is
+recognized. The general form of an item in 'comments' is:
+
+ {flags}:{text}
+
+The {flags} part can be empty, as in this case.
+ Several of these items can be concatenated, separated by commas. This
+allows recognizing different types of comments at the same time. For example,
+let's edit an e-mail message. When replying, the text that others wrote is
+preceded with ">" and "!" characters. This command would work: >
+
+ :set comments=n:>,n:!
+
+There are two items, one for comments starting with ">" and one for comments
+that start with "!". Both use the flag "n". This means that these comments
+nest. Thus a line starting with ">" may have another comment after the ">".
+This allows formatting a message like this:
+
+ > ! Did you see that site? ~
+ > ! It looks really great. ~
+ > I don't like it. The ~
+ > colors are terrible. ~
+ What is the URL of that ~
+ site? ~
+
+Try setting 'textwidth' to a different value, e.g., 80, and format the text by
+Visually selecting it and typing "gq". The result is:
+
+ > ! Did you see that site? It looks really great. ~
+ > I don't like it. The colors are terrible. ~
+ What is the URL of that site? ~
+
+You will notice that Vim did not move text from one type of comment to
+another. The "I" in the second line would have fit at the end of the first
+line, but since that line starts with "> !" and the second line with ">", Vim
+knows that this is a different kind of comment.
+
+
+A THREE PART COMMENT
+
+A C comment starts with "/*", has "*" in the middle and "*/" at the end. The
+entry in 'comments' for this looks like this: >
+
+ :set comments=s1:/*,mb:*,ex:*/
+
+The start is defined with "s1:/*". The "s" indicates the start of a
+three-piece comment. The colon separates the flags from the text by which the
+comment is recognized: "/*". There is one flag: "1". This tells Vim that the
+middle part has an offset of one space.
+ The middle part "mb:*" starts with "m", which indicates it is a middle
+part. The "b" flag means that a blank must follow the text. Otherwise Vim
+would consider text like "*pointer" also to be the middle of a comment.
+ The end part "ex:*/" has the "e" for identification. The "x" flag has a
+special meaning. It means that after Vim automatically inserted a star,
+typing / will remove the extra space.
+
+For more details see |format-comments|.
+
+==============================================================================
+
+Next chapter: |usr_31.txt| Exploiting the GUI
+
+Copyright: see |manual-copyright| vim:tw=78:ts=8:ft=help:norl: