syntax.txt

MSYS在windows下模拟了一个类unix的终端

>  let eiffel_ise=1

Finally, some vendors support hexadecimal constants. To handle them, add

>  let eiffel_hex_constants=1

to your startup file.


ERLANG							*erlang.vim*

The erlang highlighting supports Erlang (ERicsson LANGuage).
Erlang is case sensitive and default extension is ".erl".

You can disable some highlighting groups if you put the following commands in
your .vimrc file:

This command will disable comments, operators, strings and numbers:
>	let erlang_characters=1

And for disabling keywords and functions you may use:
>	let erlang_functions=1
>	let erlang_keywords=1


FORM                                                 *form.vim*

The coloring scheme for syntax elements in the FORM file uses the default
modes Conditional, Number, Statement, Comment, PreProc, Type, and String,
following the language specifications in 'Symbolic Manipulation with FORM'' by
J.A.M. Vermaseren, CAN, Netherlands, 1991.

If you want include your own changes to the default colors, you have to
redefine the following syntax groups:

    - formConditional
    - formNumber
    - formStatement
    - formHeaderStatement
    - formComment
    - formPreProc
    - formDirective
    - formType
    - formString

Note that the form.vim syntax file implements FORM preprocessor commands and
directives per default in the same syntax group.

A predefined enhanced color mode for FORM is available to distinguish between
header statements and statements in the body of a FORM program. To activate
this mode define the following variable in your vimrc file

>   let form_enhanced_color=1

The enhanced mode also takes advantage of additional color features for a dark
gvim display. Here, statements are colored LightYellow instead of Yellow, and
conditionals are LightBlue for better distinction.


FORTRAN							*fortran.vim*

Default highlighting and dialect ~
Highlighting appropriate for f95 (Fortran 95) is used by default. This choice
should be appropriate for most users most of the time because Fortran 95 is a
superset of Fortran 90 and almost a superset of Fortran 77.

Fortran source code form ~
Fortran 9x code can be in either fixed or free source form. Note that the
syntax highlighting will not be correct if the form is incorrectly set.

When you create a new fortran file, the syntax script assumes fixed source
form. If you always use free source form, then
>   :let fortran_free_source=1
in your .vimrc prior to the :syntax on command.
If the form of the source code depends upon the file extension, then it is
most convenient to set fortran_free_source with an autocommand.

When you edit an existing fortran file, the syntax script will assume free
source form if the fortran_free_source variable has been set. If it has not
been set, the syntax script attempts to determine which source form has been
used by examining the first five columns of the first 25 lines of your file.
If no signs of free source form are detected, then the file is assumed to be
in fixed source form. The algorithm should work in the vast majority of cases.
In some cases, such as a file that begins with 25 or more full-line comments,
the script may incorrectly decide that the fortran code is in fixed form. If
that happens, just add a non-comment statement beginning anywhere in the first
five columns of the first twenty five lines, save (:w) and then reload (:e!)
the file.

Tabs in fortran files ~
Tabs are not recognized by the Fortran standards. Tabs are not a good idea in
fixed format fortran source code which requires fixed column boundaries.
Therefore, tabs are marked as errors. Nevertheless, some programmers like
using tabs. If your fortran files contain tabs, then you should set the
variable fortran_have_tabs in your .vimrc with a command such as
>    :let fortran_have_tabs=1
placed prior to the :syntax on command. Unfortunately, the use of tabs will
mean that the syntax file will not be able to detect incorrect margins.

Non-default fortran dialects ~
The syntax script supports five Fortran dialects: f95, f90, f77, the Lahey
subset elf90, and the Imagine1 subset F.

If you use f77 with extensions, even common ones like do/enddo loops, do/while
loops and free source form that are supported by most f77 compilers including
g77 (GNU Fortran), then you will probably find the default highlighting
satisfactory. However, if you use strict f77 with no extensions, not even free
source form or the MIL STD 1753 extensions, then the advantages of setting the
dialect to f77 are that names such as SUM are recognized as user variable
names and not highlighted as f9x intrinsic functions, that obsolete constructs
such as ASSIGN statements are not highlighted as todo items, and that fixed
source form will be assumed.

If you use elf90 or F, the advantage of setting the dialect appropriately is
that f90 features excluded from these dialects will be highlighted as todo
items and that free source form will be assumed as required for these
dialects.

The dialect can be selected by setting the variable fortran_dialect. The
permissible values of fortran_dialect are case-sensitive and must be "f95",
"f90", "f77", "elf" or "F". Invalid values of fortran_dialect are ignored.

If all your fortran files use the same dialect, set fortran_dialect in your
.vimrc prior to your syntax on statement. If the dialect depends upon the file
extension, then it is most convenient to use autocommands.

Finer control is necessary if the file extension does not uniquely identify
the dialect. You can override the default dialect, on a file-by-file basis, by
including a comment with the directive "fortran_dialect=xx" (where xx=f77 or
elf or F or f90 or f95) in one of the first three lines in your file. For
example, your older .f files may be written in extended f77 but your newer
ones may be F codes, and you would identify the latter by including in the
first three lines of those files a Fortran comment of the form
>  ! fortran_dialect=F
F overrides elf if both directives are present.

Limitations ~
Parenthesis checking does not catch too few closing parentheses. Hollerith
strings are not recognized. Some keywords may be highlighted incorrectly
because Fortran90 has no reserved words.


FVWM CONFIGURATION FILES				*fvwm.vim*

In order for Vim to recognize Fvwm configuration files that do not match
the patterns *fvwmrc* or *fvwm2rc*, you must put additional patterns
appropriate to your system in your myfiletypes.vim file.  For these
patterns, you must set the variable "b:fvwm_version" to the major version
number of Fvwm, and the 'filetype' option to fvwm.

For example, to make Vim identify all files in /etc/X11/fvwm2/
as Fvwm2 configuration files, add the following:

>  au! BufNewFile,BufRead /etc/X11/fvwm2/*  let b:fvwm_version = 2 |
>                                         \ set filetype=fvwm

If you'd like Vim to highlight all valid color names, tell it where to
find the color database (rgb.txt) on your system.  Do this by setting
"rgb_file" to its location.  Assuming your color database is located
in /usr/X11/lib/X11/, you should add the line

>  let rgb_file = "/usr/X11/lib/X11/rgb.txt"

to your .vimrc file.


GSP							*gsp.vim*

The default coloring style for GSP pages is defined by |html.vim|, and
the coloring for java code (within java tags or inline between backticks)
is defined by |java.vim|.  The following HTML groups defined in |html.vim|
are redefined to incorporate and highlight inline java code:

    htmlString
    htmlValue
    htmlEndTag
    htmlTag
    htmlTagN

Highlighting should look fine most of the places where you'd see inline
java code, but in some special cases it may not.  To add another HTML
group where you will have inline java code where it does not highlight
correctly, just copy the line you want from |html.vim| and add gspJava
to the contains clause.

The backticks for inline java are highlighted according to the htmlError
group to make them easier to see.


HTML							*html.vim*

The coloring scheme for tags in the HTML file works as follows.

The  <> of opening tags are colored differently than the </> of a closing tag.
This is on purpose! For opening tags the 'Function' color is used, while for
closing tags the 'Type' color is used (See syntax.vim to check how those are
defined for you)

Known tag names are colored the same way as statements in C.  Unknown tag
names are colored with the same color as the <> or </> respectively which
makes it easy to spot errors

Note that the same is true for argument (or attribute) names. Known attribute
names are colored differently than unknown ones.

Some HTML tags are used to change the rendering of text. The following tags
are recognized by the html.vim syntax coloring file and change the way normal
text is shown: <B> <I> <U> <EM> <STRONG> (<EM> is used as an alias for <I>,
while <STRONG> as an alias for <B>), <H1> - <H6>, <HEAD>, <TITLE> and <A>, but
only if used as a link that is, it must include a href as in
<A href="somfile.html">).

If you want to change how such text is rendered, you must redefine the
following syntax groups:

    - htmlBold
    - htmlBoldUnderline
    - htmlBoldUnderlineItalic
    - htmlUnderline
    - htmlUnderlineItalic
    - htmlItalic
    - htmlLink for links
    - htmlTitle for titles
    - htmlH1 - htmlH6 for headings

To make this redefinition work you must redefine them all with the exception
of the last two (htmlTitle and htmlH[1-6], which are optional) and define the
following variable in your vimrc (this is due to the order in which the files
are read during initialization)
>   let html_my_rendering=1

If you'd like to see an example download mysyntax.vim at
http://www.fleiner.com/vim/mysyntax.vim

You can also disable this rendering by adding the following line to your
vimrc file:
>   let html_no_rendering=1

HTML comments are rather special (see an HTML reference document for the
details), and the syntax coloring scheme will highlight all errors.
However, if you prefer to use the wrong style (starts with <!-- and
ends with --!>) you can define
>   let html_wrong_comments=1

JavaScript and Visual Basic embedded inside HTML documents are highlighted as
'Special' with statements, comments, strings and so on colored as in standard
programming languages. Note that only JavaScript and Visual Basic are currently
supported, no other scripting language has been added yet.

Embedded and inlined cascading style sheets (CSS) are highlighted too.

There are several html preprocessor languages out there. html.vim has been
written such that it should be trivial to include it. To do so add the
following two lines to the syntax coloring file for that language
(the example comes from the asp.vim file):

    source <sfile>:p:h/html.vim
    syn cluster htmlPreproc add=asp

Now you just need to make sure that you add all regions that contain
the preprocessor language to the cluster htmlPreproc.


HTML/OS (by Aestiva)					*htmlos.vim*

The coloring scheme for HTML/OS works as follows:

Functions and variable names are the same color by default, because VIM
doesn't specify different colors for Functions and Identifiers.  To change
this (which is recommended if you want function names to be recognizable in a
different color) you need to add the following line to either your ~/.vimrc:
> :hi Function term=underline cterm=bold ctermfg=LightGray

Of course, the ctermfg can be a different color if you choose.

Another issues that HTML/OS runs into is that there is no special filetype to
signify that it is a file with HTML/OS coding.  You can change this by opening
a file and turning on HTML/OS syntax by doing the following:
> :set syntax=htmlos

Lastly, it should be noted that the opening and closing characters to begin a
block of HTML/OS code can either be << or [[ and >> or ]], respectively.


IA64						    *ia64.vim* *intel-itanium*

Highlighting for the Intel Itanium 64 assembly language.  See |asm.vim| for
how to recognize this filetype.

To have *.inc files be recognized as IA64, add this to your .vimrc file:
>	:let g:filetype_inc = "ia64"


INFORM                                                  *inform.vim*

Inform highlighting includes symbols provided by the Inform Library, as
most programs make extensive use of it.  If do not wish Library symbols
to be highlighted add this to your vim startup:
>   let inform_highlight_simple=1

By default it is assumed that Inform programs are Z-machine targetted,
and highlights Z-machine assembly language symbols appropriately.  If
you intend your program to be targetted to a Glulx/Glk environment you
need to add this to your startup sequence:
>   let inform_highlight_glulx=1

This will highlight Glulx opcodes instead, and also adds glk() to the
set of highlighted system functions.


JAVA							*java.vim*

The java.vim syntax highlighting file offers several options:

In Java 1.0.2 it was never possible to have braces inside parens, so this was
flagged as an error.  Since Java 1.1 this is possible (with anonymous
classes), and therefore is no longer marked as an error. If you prefer the old
way, put the following line into your vim startup file:
>  let java_mark_braces_in_parens_as_errors=1

All identifiers in java.lang.* are always visible in all classes.  To
highlight them use:
>  let java_highlight_java_lang_ids=1

You can also highlight identifiers of most standard java packages
if you download the script at http://www.fleiner.com/vim/syntax/javaid.vim
If you prefer to only highlight identifiers of a certain package, say
java.io use the following:
>  let java_highligh_java_io=1
Check the javaid.vim file for a list of all the packages that are supported.

Function names are not highlighted, as the way to find functions depends on
how you write java code.  The syntax file knows two possible ways to highlight
functions:

If you write function declarations that are always indented by either
a tab, 8 spaces or 2 spaces you may want to set
>  let java_highlight_functions="indent"