diff options
Diffstat (limited to 'runtime/doc/usr_44.txt')
| -rw-r--r-- | runtime/doc/usr_44.txt | 708 |
1 files changed, 708 insertions, 0 deletions
diff --git a/runtime/doc/usr_44.txt b/runtime/doc/usr_44.txt new file mode 100644 index 0000000..1d1b5a1 --- /dev/null +++ b/runtime/doc/usr_44.txt @@ -0,0 +1,708 @@ +*usr_44.txt* For Vim version 9.1. Last change: 2017 May 06 + + VIM USER MANUAL - by Bram Moolenaar + + Your own syntax highlighted + + +Vim comes with highlighting for a couple of hundred different file types. If +the file you are editing isn't included, read this chapter to find out how to +get this type of file highlighted. Also see |:syn-define| in the reference +manual. + +|44.1| Basic syntax commands +|44.2| Keywords +|44.3| Matches +|44.4| Regions +|44.5| Nested items +|44.6| Following groups +|44.7| Other arguments +|44.8| Clusters +|44.9| Including another syntax file +|44.10| Synchronizing +|44.11| Installing a syntax file +|44.12| Portable syntax file layout + + Next chapter: |usr_45.txt| Select your language + Previous chapter: |usr_43.txt| Using filetypes +Table of contents: |usr_toc.txt| + +============================================================================== +*44.1* Basic syntax commands + +Using an existing syntax file to start with will save you a lot of time. Try +finding a syntax file in $VIMRUNTIME/syntax for a language that is similar. +These files will also show you the normal layout of a syntax file. To +understand it, you need to read the following. + +Let's start with the basic arguments. Before we start defining any new +syntax, we need to clear out any old definitions: > + + :syntax clear + +This isn't required in the final syntax file, but very useful when +experimenting. + +There are more simplifications in this chapter. If you are writing a syntax +file to be used by others, read all the way through the end to find out the +details. + + +LISTING DEFINED ITEMS + +To check which syntax items are currently defined, use this command: > + + :syntax + +You can use this to check which items have actually been defined. Quite +useful when you are experimenting with a new syntax file. It also shows the +colors used for each item, which helps to find out what is what. + To list the items in a specific syntax group use: > + + :syntax list {group-name} + +This also can be used to list clusters (explained in |44.8|). Just include +the @ in the name. + + +MATCHING CASE + +Some languages are not case sensitive, such as Pascal. Others, such as C, are +case sensitive. You need to tell which type you have with the following +commands: > + :syntax case match + :syntax case ignore + +The "match" argument means that Vim will match the case of syntax elements. +Therefore, "int" differs from "Int" and "INT". If the "ignore" argument is +used, the following are equivalent: "Procedure", "PROCEDURE" and "procedure". + The ":syntax case" commands can appear anywhere in a syntax file and affect +the syntax definitions that follow. In most cases, you have only one ":syntax +case" command in your syntax file; if you work with an unusual language that +contains both case-sensitive and non-case-sensitive elements, however, you can +scatter the ":syntax case" command throughout the file. + +============================================================================== +*44.2* Keywords + +The most basic syntax elements are keywords. To define a keyword, use the +following form: > + + :syntax keyword {group} {keyword} ... + +The {group} is the name of a syntax group. With the ":highlight" command you +can assign colors to a {group}. The {keyword} argument is an actual keyword. +Here are a few examples: > + + :syntax keyword xType int long char + :syntax keyword xStatement if then else endif + +This example uses the group names "xType" and "xStatement". By convention, +each group name is prefixed by the filetype for the language being defined. +This example defines syntax for the x language (eXample language without an +interesting name). In a syntax file for "csh" scripts the name "cshType" +would be used. Thus the prefix is equal to the value of 'filetype'. + These commands cause the words "int", "long" and "char" to be highlighted +one way and the words "if", "then", "else" and "endif" to be highlighted +another way. Now you need to connect the x group names to standard Vim +names. You do this with the following commands: > + + :highlight link xType Type + :highlight link xStatement Statement + +This tells Vim to highlight "xType" like "Type" and "xStatement" like +"Statement". See |group-name| for the standard names. + + +UNUSUAL KEYWORDS + +The characters used in a keyword must be in the 'iskeyword' option. If you +use another character, the word will never match. Vim doesn't give a warning +message for this. + The x language uses the '-' character in keywords. This is how it's done: +> + :setlocal iskeyword+=- + :syntax keyword xStatement when-not + +The ":setlocal" command is used to change 'iskeyword' only for the current +buffer. Still it does change the behavior of commands like "w" and "*". If +that is not wanted, don't define a keyword but use a match (explained in the +next section). + +The x language allows for abbreviations. For example, "next" can be +abbreviated to "n", "ne" or "nex". You can define them by using this command: +> + :syntax keyword xStatement n[ext] + +This doesn't match "nextone", keywords always match whole words only. + +============================================================================== +*44.3* Matches + +Consider defining something a bit more complex. You want to match ordinary +identifiers. To do this, you define a match syntax item. This one matches +any word consisting of only lowercase letters: > + + :syntax match xIdentifier /\<\l\+\>/ +< + Note: + Keywords overrule any other syntax item. Thus the keywords "if", + "then", etc., will be keywords, as defined with the ":syntax keyword" + commands above, even though they also match the pattern for + xIdentifier. + +The part at the end is a pattern, like it's used for searching. The // is +used to surround the pattern (like how it's done in a ":substitute" command). +You can use any other character, like a plus or a quote. + +Now define a match for a comment. In the x language it is anything from # to +the end of a line: > + + :syntax match xComment /#.*/ + +Since you can use any search pattern, you can highlight very complex things +with a match item. See |pattern| for help on search patterns. + +============================================================================== +*44.4* Regions + +In the example x language, strings are enclosed in double quotation marks ("). +To highlight strings you define a region. You need a region start (double +quote) and a region end (double quote). The definition is as follows: > + + :syntax region xString start=/"/ end=/"/ + +The "start" and "end" directives define the patterns used to find the start +and end of the region. But what about strings that look like this? + + "A string with a double quote (\") in it" ~ + +This creates a problem: The double quotation marks in the middle of the string +will end the region. You need to tell Vim to skip over any escaped double +quotes in the string. Do this with the skip keyword: > + + :syntax region xString start=/"/ skip=/\\"/ end=/"/ + +The double backslash matches a single backslash, since the backslash is a +special character in search patterns. + +When to use a region instead of a match? The main difference is that a match +item is a single pattern, which must match as a whole. A region starts as +soon as the "start" pattern matches. Whether the "end" pattern is found or +not doesn't matter. Thus when the item depends on the "end" pattern to match, +you cannot use a region. Otherwise, regions are often simpler to define. And +it is easier to use nested items, as is explained in the next section. + +============================================================================== +*44.5* Nested items + +Take a look at this comment: + + %Get input TODO: Skip white space ~ + +You want to highlight TODO in big yellow letters, even though it is in a +comment that is highlighted blue. To let Vim know about this, you define the +following syntax groups: > + + :syntax keyword xTodo TODO contained + :syntax match xComment /%.*/ contains=xTodo + +In the first line, the "contained" argument tells Vim that this keyword can +exist only inside another syntax item. The next line has "contains=xTodo". +This indicates that the xTodo syntax element is inside it. The result is that +the comment line as a whole is matched with "xComment" and made blue. The +word TODO inside it is matched by xTodo and highlighted yellow (highlighting +for xTodo was setup for this). + + +RECURSIVE NESTING + +The x language defines code blocks in curly braces. And a code block may +contain other code blocks. This can be defined this way: > + + :syntax region xBlock start=/{/ end=/}/ contains=xBlock + +Suppose you have this text: + + while i < b { ~ + if a { ~ + b = c; ~ + } ~ + } ~ + +First a xBlock starts at the { in the first line. In the second line another +{ is found. Since we are inside a xBlock item, and it contains itself, a +nested xBlock item will start here. Thus the "b = c" line is inside the +second level xBlock region. Then a } is found in the next line, which matches +with the end pattern of the region. This ends the nested xBlock. Because the +} is included in the nested region, it is hidden from the first xBlock region. +Then at the last } the first xBlock region ends. + + +KEEPING THE END + +Consider the following two syntax items: > + + :syntax region xComment start=/%/ end=/$/ contained + :syntax region xPreProc start=/#/ end=/$/ contains=xComment + +You define a comment as anything from % to the end of the line. A +preprocessor directive is anything from # to the end of the line. Because you +can have a comment on a preprocessor line, the preprocessor definition +includes a "contains=xComment" argument. Now look what happens with this +text: + + #define X = Y % Comment text ~ + int foo = 1; ~ + +What you see is that the second line is also highlighted as xPreProc. The +preprocessor directive should end at the end of the line. That is why +you have used "end=/$/". So what is going wrong? + The problem is the contained comment. The comment starts with % and ends +at the end of the line. After the comment ends, the preprocessor syntax +continues. This is after the end of the line has been seen, so the next +line is included as well. + To avoid this problem and to avoid a contained syntax item eating a needed +end of line, use the "keepend" argument. This takes care of +the double end-of-line matching: > + + :syntax region xComment start=/%/ end=/$/ contained + :syntax region xPreProc start=/#/ end=/$/ contains=xComment keepend + + +CONTAINING MANY ITEMS + +You can use the contains argument to specify that everything can be contained. +For example: > + + :syntax region xList start=/\[/ end=/\]/ contains=ALL + +All syntax items will be contained in this one. It also contains itself, but +not at the same position (that would cause an endless loop). + You can specify that some groups are not contained. Thus contain all +groups but the ones that are listed: +> + :syntax region xList start=/\[/ end=/\]/ contains=ALLBUT,xString + +With the "TOP" item you can include all items that don't have a "contained" +argument. "CONTAINED" is used to only include items with a "contained" +argument. See |:syn-contains| for the details. + +============================================================================== +*44.6* Following groups + +The x language has statements in this form: + + if (condition) then ~ + +You want to highlight the three items differently. But "(condition)" and +"then" might also appear in other places, where they get different +highlighting. This is how you can do this: > + + :syntax match xIf /if/ nextgroup=xIfCondition skipwhite + :syntax match xIfCondition /([^)]*)/ contained nextgroup=xThen skipwhite + :syntax match xThen /then/ contained + +The "nextgroup" argument specifies which item can come next. This is not +required. If none of the items that are specified are found, nothing happens. +For example, in this text: + + if not (condition) then ~ + +The "if" is matched by xIf. "not" doesn't match the specified nextgroup +xIfCondition, thus only the "if" is highlighted. + +The "skipwhite" argument tells Vim that white space (spaces and tabs) may +appear in between the items. Similar arguments are "skipnl", which allows a +line break in between the items, and "skipempty", which allows empty lines. +Notice that "skipnl" doesn't skip an empty line, something must match after +the line break. + +============================================================================== +*44.7* Other arguments + +MATCHGROUP + +When you define a region, the entire region is highlighted according to the +group name specified. To highlight the text enclosed in parentheses () with +the group xInside, for example, use the following command: > + + :syntax region xInside start=/(/ end=/)/ + +Suppose, that you want to highlight the parentheses differently. You can do +this with a lot of convoluted region statements, or you can use the +"matchgroup" argument. This tells Vim to highlight the start and end of a +region with a different highlight group (in this case, the xParen group): > + + :syntax region xInside matchgroup=xParen start=/(/ end=/)/ + +The "matchgroup" argument applies to the start or end match that comes after +it. In the previous example both start and end are highlighted with xParen. +To highlight the end with xParenEnd: > + + :syntax region xInside matchgroup=xParen start=/(/ + \ matchgroup=xParenEnd end=/)/ + +A side effect of using "matchgroup" is that contained items will not match in +the start or end of the region. The example for "transparent" uses this. + + +TRANSPARENT + +In a C language file you would like to highlight the () text after a "while" +differently from the () text after a "for". In both of these there can be +nested () items, which should be highlighted in the same way. You must make +sure the () highlighting stops at the matching ). This is one way to do this: +> + :syntax region cWhile matchgroup=cWhile start=/while\s*(/ end=/)/ + \ contains=cCondNest + :syntax region cFor matchgroup=cFor start=/for\s*(/ end=/)/ + \ contains=cCondNest + :syntax region cCondNest start=/(/ end=/)/ contained transparent + +Now you can give cWhile and cFor different highlighting. The cCondNest item +can appear in either of them, but take over the highlighting of the item it is +contained in. The "transparent" argument causes this. + Notice that the "matchgroup" argument has the same group as the item +itself. Why define it then? Well, the side effect of using a matchgroup is +that contained items are not found in the match with the start item then. +This avoids that the cCondNest group matches the ( just after the "while" or +"for". If this would happen, it would span the whole text until the matching +) and the region would continue after it. Now cCondNest only matches after +the match with the start pattern, thus after the first (. + + +OFFSETS + +Suppose you want to define a region for the text between ( and ) after an +"if". But you don't want to include the "if" or the ( and ). You can do this +by specifying offsets for the patterns. Example: > + + :syntax region xCond start=/if\s*(/ms=e+1 end=/)/me=s-1 + +The offset for the start pattern is "ms=e+1". "ms" stands for Match Start. +This defines an offset for the start of the match. Normally the match starts +where the pattern matches. "e+1" means that the match now starts at the end +of the pattern match, and then one character further. + The offset for the end pattern is "me=s-1". "me" stands for Match End. +"s-1" means the start of the pattern match and then one character back. The +result is that in this text: + + if (foo == bar) ~ + +Only the text "foo == bar" will be highlighted as xCond. + +More about offsets here: |:syn-pattern-offset|. + + +ONELINE + +The "oneline" argument indicates that the region does not cross a line +boundary. For example: > + + :syntax region xIfThen start=/if/ end=/then/ oneline + +This defines a region that starts at "if" and ends at "then". But if there is +no "then" after the "if", the region doesn't match. + + Note: + When using "oneline" the region doesn't start if the end pattern + doesn't match in the same line. Without "oneline" Vim does _not_ + check if there is a match for the end pattern. The region starts even + when the end pattern doesn't match in the rest of the file. + + +CONTINUATION LINES AND AVOIDING THEM + +Things now become a little more complex. Let's define a preprocessor line. +This starts with a # in the first column and continues until the end of the +line. A line that ends with \ makes the next line a continuation line. The +way you handle this is to allow the syntax item to contain a continuation +pattern: > + + :syntax region xPreProc start=/^#/ end=/$/ contains=xLineContinue + :syntax match xLineContinue "\\$" contained + +In this case, although xPreProc normally matches a single line, the group +contained in it (namely xLineContinue) lets it go on for more than one line. +For example, it would match both of these lines: + + #define SPAM spam spam spam \ ~ + bacon and spam ~ + +In this case, this is what you want. If it is not what you want, you can call +for the region to be on a single line by adding "excludenl" to the contained +pattern. For example, you want to highlight "end" in xPreProc, but only at +the end of the line. To avoid making the xPreProc continue on the next line, +like xLineContinue does, use "excludenl" like this: > + + :syntax region xPreProc start=/^#/ end=/$/ + \ contains=xLineContinue,xPreProcEnd + :syntax match xPreProcEnd excludenl /end$/ contained + :syntax match xLineContinue "\\$" contained + +"excludenl" must be placed before the pattern. Since "xLineContinue" doesn't +have "excludenl", a match with it will extend xPreProc to the next line as +before. + +============================================================================== +*44.8* Clusters + +One of the things you will notice as you start to write a syntax file is that +you wind up generating a lot of syntax groups. Vim enables you to define a +collection of syntax groups called a cluster. + Suppose you have a language that contains for loops, if statements, while +loops, and functions. Each of them contains the same syntax elements: numbers +and identifiers. You define them like this: > + + :syntax match xFor /^for.*/ contains=xNumber,xIdent + :syntax match xIf /^if.*/ contains=xNumber,xIdent + :syntax match xWhile /^while.*/ contains=xNumber,xIdent + +You have to repeat the same "contains=" every time. If you want to add +another contained item, you have to add it three times. Syntax clusters +simplify these definitions by enabling you to have one cluster stand for +several syntax groups. + To define a cluster for the two items that the three groups contain, use +the following command: > + + :syntax cluster xState contains=xNumber,xIdent + +Clusters are used inside other syntax items just like any syntax group. +Their names start with @. Thus, you can define the three groups like this: > + + :syntax match xFor /^for.*/ contains=@xState + :syntax match xIf /^if.*/ contains=@xState + :syntax match xWhile /^while.*/ contains=@xState + +You can add new group names to this cluster with the "add" argument: > + + :syntax cluster xState add=xString + +You can remove syntax groups from this list as well: > + + :syntax cluster xState remove=xNumber + +============================================================================== +*44.9* Including another syntax file + +The C++ language syntax is a superset of the C language. Because you do not +want to write two syntax files, you can have the C++ syntax file read in the +one for C by using the following command: > + + :runtime! syntax/c.vim + +The ":runtime!" command searches 'runtimepath' for all "syntax/c.vim" files. +This makes the C parts of the C++ syntax be defined like for C files. If you +have replaced the c.vim syntax file, or added items with an extra file, these +will be loaded as well. + After loading the C syntax items the specific C++ items can be defined. +For example, add keywords that are not used in C: > + + :syntax keyword cppStatement new delete this friend using + +This works just like in any other syntax file. + +Now consider the Perl language. A Perl script consists of two distinct parts: +a documentation section in POD format, and a program written in Perl itself. +The POD section starts with "=head" and ends with "=cut". + You want to define the POD syntax in one file, and use it from the Perl +syntax file. The ":syntax include" command reads in a syntax file and stores +the elements it defined in a syntax cluster. For Perl, the statements are as +follows: > + + :syntax include @Pod <sfile>:p:h/pod.vim + :syntax region perlPOD start=/^=head/ end=/^=cut/ contains=@Pod + +When "=head" is found in a Perl file, the perlPOD region starts. In this +region the @Pod cluster is contained. All the items defined as top-level +items in the pod.vim syntax files will match here. When "=cut" is found, the +region ends and we go back to the items defined in the Perl file. + The ":syntax include" command is clever enough to ignore a ":syntax clear" +command in the included file. And an argument such as "contains=ALL" will +only contain items defined in the included file, not in the file that includes +it. + The "<sfile>:p:h/" part uses the name of the current file (<sfile>), +expands it to a full path (:p) and then takes the head (:h). This results in +the directory name of the file. This causes the pod.vim file in the same +directory to be included. + +============================================================================== +*44.10* Synchronizing + +Compilers have it easy. They start at the beginning of a file and parse it +straight through. Vim does not have it so easy. It must start in the middle, +where the editing is being done. So how does it tell where it is? + The secret is the ":syntax sync" command. This tells Vim how to figure out +where it is. For example, the following command tells Vim to scan backward +for the beginning or end of a C-style comment and begin syntax coloring from +there: > + + :syntax sync ccomment + +You can tune this processing with some arguments. The "minlines" argument +tells Vim the minimum number of lines to look backward, and "maxlines" tells +the editor the maximum number of lines to scan. + For example, the following command tells Vim to look at least 10 lines +before the top of the screen: > + + :syntax sync ccomment minlines=10 maxlines=500 + +If it cannot figure out where it is in that space, it starts looking farther +and farther back until it figures out what to do. But it looks no farther +back than 500 lines. (A large "maxlines" slows down processing. A small one +might cause synchronization to fail.) + To make synchronizing go a bit faster, tell Vim which syntax items can be +skipped. Every match and region that only needs to be used when actually +displaying text can be given the "display" argument. + By default, the comment to be found will be colored as part of the Comment +syntax group. If you want to color things another way, you can specify a +different syntax group: > + + :syntax sync ccomment xAltComment + +If your programming language does not have C-style comments in it, you can try +another method of synchronization. The simplest way is to tell Vim to space +back a number of lines and try to figure out things from there. The following +command tells Vim to go back 150 lines and start parsing from there: > + + :syntax sync minlines=150 + +A large "minlines" value can make Vim slower, especially when scrolling +backwards in the file. + Finally, you can specify a syntax group to look for by using this command: +> + :syntax sync match {sync-group-name} + \ grouphere {group-name} {pattern} + +This tells Vim that when it sees {pattern} the syntax group named {group-name} +begins just after the pattern given. The {sync-group-name} is used to give a +name to this synchronization specification. For example, the sh scripting +language begins an if statement with "if" and ends it with "fi": + + if [ --f file.txt ] ; then ~ + echo "File exists" ~ + fi ~ + +To define a "grouphere" directive for this syntax, you use the following +command: > + + :syntax sync match shIfSync grouphere shIf "\<if\>" + +The "groupthere" argument tells Vim that the pattern ends a group. For +example, the end of the if/fi group is as follows: > + + :syntax sync match shIfSync groupthere NONE "\<fi\>" + +In this example, the NONE tells Vim that you are not in any special syntax +region. In particular, you are not inside an if block. + +You also can define matches and regions that are with no "grouphere" or +"groupthere" arguments. These groups are for syntax groups skipped during +synchronization. For example, the following skips over anything inside {}, +even if it would normally match another synchronization method: > + + :syntax sync match xSpecial /{.*}/ + +More about synchronizing in the reference manual: |:syn-sync|. + +============================================================================== +*44.11* Installing a syntax file + +When your new syntax file is ready to be used, drop it in a "syntax" directory +in 'runtimepath'. For Unix that would be "~/.vim/syntax". + The name of the syntax file must be equal to the file type, with ".vim" +added. Thus for the x language, the full path of the file would be: + + ~/.vim/syntax/x.vim ~ + +You must also make the file type be recognized. See |43.2|. + +If your file works well, you might want to make it available to other Vim +users. First read the next section to make sure your file works well for +others. Then e-mail it to the Vim maintainer: <maintainer@vim.org>. Also +explain how the filetype can be detected. With a bit of luck your file will +be included in the next Vim version! + + +ADDING TO AN EXISTING SYNTAX FILE + +We were assuming you were adding a completely new syntax file. When an existing +syntax file works, but is missing some items, you can add items in a separate +file. That avoids changing the distributed syntax file, which will be lost +when installing a new version of Vim. + Write syntax commands in your file, possibly using group names from the +existing syntax. For example, to add new variable types to the C syntax file: +> + :syntax keyword cType off_t uint + +Write the file with the same name as the original syntax file. In this case +"c.vim". Place it in a directory near the end of 'runtimepath'. This makes +it loaded after the original syntax file. For Unix this would be: + + ~/.vim/after/syntax/c.vim ~ + +============================================================================== +*44.12* Portable syntax file layout + +Wouldn't it be nice if all Vim users exchange syntax files? To make this +possible, the syntax file must follow a few guidelines. + +Start with a header that explains what the syntax file is for, who maintains +it and when it was last updated. Don't include too much information about +changes history, not many people will read it. Example: > + + " Vim syntax file + " Language: C + " Maintainer: Bram Moolenaar <Bram@vim.org> + " Last Change: 2001 Jun 18 + " Remark: Included by the C++ syntax. + +Use the same layout as the other syntax files. Using an existing syntax file +as an example will save you a lot of time. + +Choose a good, descriptive name for your syntax file. Use lowercase letters +and digits. Don't make it too long, it is used in many places: The name of +the syntax file "name.vim", 'filetype', b:current_syntax and the start of each +syntax group (nameType, nameStatement, nameString, etc). + +Start with a check for "b:current_syntax". If it is defined, some other +syntax file, earlier in 'runtimepath' was already loaded: > + + if exists("b:current_syntax") + finish + endif + +Set "b:current_syntax" to the name of the syntax at the end. Don't forget +that included files do this too, you might have to reset "b:current_syntax" if +you include two files. + +Do not include anything that is a user preference. Don't set 'tabstop', +'expandtab', etc. These belong in a filetype plugin. + +Do not include mappings or abbreviations. Only include setting 'iskeyword' if +it is really necessary for recognizing keywords. + +To allow users select their own preferred colors, make a different group name +for every kind of highlighted item. Then link each of them to one of the +standard highlight groups. That will make it work with every color scheme. +If you select specific colors it will look bad with some color schemes. And +don't forget that some people use a different background color, or have only +eight colors available. + +For the linking use "hi def link", so that the user can select different +highlighting before your syntax file is loaded. Example: > + + hi def link nameString String + hi def link nameNumber Number + hi def link nameCommand Statement + ... etc ... + +Add the "display" argument to items that are not used when syncing, to speed +up scrolling backwards and CTRL-L. + +============================================================================== + +Next chapter: |usr_45.txt| Select your language + +Copyright: see |manual-copyright| vim:tw=78:ts=8:noet:ft=help:norl: |