syntax.txt

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

the most prevalent version currently.

Note, not all PS interpreters will support all language features for a
particular language level.  In particular the %!PS-Adobe-3.0 at the start of
PS files does NOT mean the PostScript present is level 3 PostScript!

If you are working with Display PostScript, you can include highlighting of
Display PS language features by defining the postscr_display variable as
follows:

>  let postscr_display=1

If you are working with Ghostscript, you can include highlighting of
Ghostscript specific language features by defining the variable
postscr_ghostscript as follows:

>  let postscr_ghostscript=1

PostScript is a large language, with many predefined elements.  While it
useful to have all these elements highlighted, on slower machines this can
cause Vim to slow down.  In an attempt to be machine friendly font names and
character encodings are not highlighted by default.  Unless you are working
explicitly with either of these this should be ok.  If you want them to be
highlighted you should set one or both of the following variables:

>  let postscr_fonts=1
>  let postscr_encodings=1

There is a stylistic option to the highlighting of and, or, and not.  In
PostScript the function of these operators depends on the types of their
operands - if the operands are booleans then they are the logical operators,
if they are integers then they are binary operators.  As binary and logical
operators can be highlighted differently they have to be highlighted one way
or the other.  By default they are treated as logical operators.  They can be
highlighted as binary operators by defining the variable
postscr_andornot_binary as follows:

>  let postscr_andornot_binary=1


PRINTCAP + TERMCAP		*ptcap.vim* *termcap-syntax* *printcap-syntax*

This syntax file applies to the printcap and termcap databases.

In order for Vim to recognize printcap/termcap files that do not match
the patterns *printcap*, or *termcap*, you must put additional patterns
appropriate to your system in your |myfiletypefile| file.  For these
patterns, you must set the variable "b:ptcap_type" to either "print" or
"term", and then the 'filetype' option to ptcap.

For example, to make Vim identify all files in /etc/termcaps/ as termcap
files, add the following:

>  au BufNewFile,BufRead /etc/termcaps/* let b:ptcap_type = "term" |
>                                       \ set filetype=ptcap

If you notice highlighting errors while scrolling backwards, which
are fixed when redrawing with CTRL-L, try setting the "ptcap_minlines"
internal variable to a larger number:

  let ptcap_minlines = 50

(The default is 20 lines.)


PROGRESS					*progress.vim*

Files matching "*.w" could be Progress or cweb.  If the automatic detection
doesn't work for you, or you don't edit cweb at all, use this in your
startup vimrc:
>   :let filetype_w = "progress"
The same happens for "*.i", which could be assembly, and "*.p", which could be
Pascal.  Use this if you don't use assembly and Pascal:
>   :let filetype_i = "progress"
>   :let filetype_p = "progress"


PYTHON							*python.vim*

There are four options to control Python syntax highlighting.

For highlighted numbers:
>  let python_highlight_numbers = 1

For highlighted builtin functions:
>  let python_highlight_builtins = 1

For highlighted standard exceptions:
>  let python_highlight_exceptions = 1

If you want all possible Python highlighting (the same as setting the
preceding three options):
>  let python_highlight_all = 1


REXX							*rexx.vim*

If you notice highlighting errors while scrolling backwards, which are fixed
when redrawing with CTRL-L, try setting the "rexx_minlines" internal variable
to a larger number:
>  let rexx_minlines = 50
This will make the syntax synchronization start 50 lines before the first
displayed line.  The default value is 10.  The disadvantage of using a larger
number is that redrawing can become slow.


RUBY							*ruby.vim*

There are a few options to the Ruby syntax highlighting.

By default, the "end" keyword is colorized according to the opening statement
of the block it closes. While useful, this feature can be expensive: if you
experience slow redrawing (or you are on a terminal with poor color support)
you may want to turn it off by defining the "ruby_no_expensive" variable:
>   let ruby_no_expensive = 1
In this case the same color will be used for all control keywords.

If you do want this feature enabled, but notice highlighting errors while
scrolling backwards, which are fixed when redrawing with CTRL-L, try setting
the "ruby_minlines" variable to a value larger than 50:
>   let ruby_minlines = 100
Ideally, this value should be a number of lines large enough to embrace your
largest class or module.

Finally, if you do not like to see too many color items around, you can define
"ruby_no_identifiers":
>   let ruby_no_identifiers = 1
This will prevent highlighting of special identifiers like "ConstantName",
"$global_var", "@instace_var", "| iterator |", and ":symbol".


SED							*sed.vim*

To make tabs stand out from regular blanks (accomplished by using Todo
highlighting on the tabs), define "highlight_sedtabs" by putting

>  let highlight_sedtabs = 1

in the vimrc file.  (This special highlighting only applies for tabs
inside search patterns, replacement texts, addresses or text included
by an Append/Change/Insert command.)  If you enable this option, it is
also a good idea to set the tab width to one character; by doing that,
you can easily count the number of tabs in a string.

Bugs:

  The transform command (y) is treated exactly like the substitute
  command.  This means that, as far as this syntax file is concerned,
  transform accepts the same flags as substitute, which is wrong.
  (Transform accepts no flags.)  I tolerate this bug because the
  involved commands need very complex treatment (95 patterns, one for
  each plausible pattern delimiter).


SGML							*sgml.vim*

The coloring scheme for tags in the SGML 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 not colored 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 SGML tags are used to change the rendering of text. The following tags
are recognized by the sgml.vim syntax coloring file and change the way normal
text is shown: <varname> <emphasis> <command> <function> <literal>
<replaceable> <ulink> and <link>.

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

    - sgmlBold
    - sgmlBoldItalic
    - sgmlUnderline
    - sgmlItalic
    - sgmlLink for links

To make this redefinition work you must redefine them all and define the
following variable in your vimrc (this is due to the order in which the files
are read during initialization)
>   let sgml_my_rendering=1

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

(Adapted from the html.vim help text by Claudio Fleiner <[e-mail]>)


SH							*sh.vim*

This covers the "normal" Unix sh, bash and the korn shell.  If you're working
on a system where bash is called sh, you will benefit to define the vim
variable 'bash_is_sh' in your '.vimrc' file:
>  let bash_is_sh = 1
If some buffers use bash for sh, use the buffer-local variable:
>  let b:is_bash = 1
You can force using the korn shell by sett a buffer-local variable:
>  let b:is_kornshell = 1

To choose between the two ways to treat single-quotes inside a pair of
double-quotes, I have introduced a Vim variable "highlight_balanced_quotes".
By default (ie by not declaring this variable) single quotes can be used
inside double quotes, and are not highlighted.  If you prefer balanced single
quotes as I do you just make the statement in your .vimrc file:
>  let highlight_balanced_quotes = 1

Similar I have introduced another vim variable "highlight_function_name" to be
used to enable/disable highlighting of the function-name in function
declaration.  Default is not to highlight the function name.  If you want to
highlight functions names, include this in your .vimrc file:
>  let highlight_function_name = 1

If you notice highlighting errors while scrolling backwards, which are fixed
when redrawing with CTRL-L, try setting the "sh_minlines" internal variable
to a larger number:
>  let sh_minlines = 200
This will make the syntax synchronization start 200 lines before the first
displayed line.  The default value is 100.  The disadvantage of using a larger
number is that redrawing can become slow.

If you don't have much to synchronize on, displaying can be very slow.  To
reduce this, the "sh_maxlines" internal variable can be set:
>  let sh_maxlines = 100
The default is to use the double of "sh_minlines".  Set it to a smaller number
to speed up displaying.  The disadvantage is that highlight errors may appear.


SPEEDUP (AspenTech plant simulator)				*spup.vim*

The Speedup syntax file has some options:

- strict_subsections : If this variable is defined, only keywords for
  sections and subsections will be highlighted as statements but not
  other keywords (like WITHIN in the OPERATION section).

- highlight_types : Definition of this variable causes stream types
  like temperature or pressure to be highlighted as Type, not as a
  plain Identifier. Included are the types that are usually found in
  the DECLARE section; if you defined own types, you have to include
  them in the syntax file.

- oneline_comments : this value ranges from 1 to 3 and determines the
  highlighting of # style comments.

  oneline_comments = 1 : allow normal Speedup code after an even
  number of #s.

  oneline_comments = 2 : show code starting with the second # as
  error. This is the default setting.

  oneline_comments = 3 : show the whole line as error if it contains
  more than one #.

Since especially OPERATION sections tend to become very large due to
PRESETting variables, syncing may be critical. If your computer is
fast enough, you can increase minlines and/or maxlines near the end of
the syntax file.


TEX							*tex.vim*

The tex highlighting supports TeX, LaTeX, and some AmsTeX.  The
highlighting supports three primary zones: normal, texZone, and texMathZone.
Although a considerable effort has been made to have these zones terminate
properly, zones delineated by $..$ and $$..$$ cannot be synchronized as
there's no difference between start and end patterns.  Consequently, a
special "TeX comment" has been provided
> %stopzone
which will forcibly terminate the highlighting of either a texZone or a
texMathZone.

If you have a slow computer, you may wish to reduce the values for
>  syn sync maxlines=200
>  syn sync minlines=50
(especially the latter).  If your computer is fast, you may wish to
increase them.  This primarily affects synchronizing (ie. just what group,
if any, is the text at the top of the screen supposed to be in?).

The <tex.vim> supports lexical error checking of various sorts.  Thus,
although the error checking is ofttimes very useful, it can indicate
errors where none actually are.  If this proves to be a problem for you,
you may put in your <.vimrc> the following statement:
>  let tex_no_error=1
and all error checking by <tex.vim> will be suppressed.


TF							*tf.vim*

There is one option for the tf syntax highlighting.

For syncing, minlines defaults to 100.  If you prefer another value, you can
set "tf_minlines" to the value you desire.  Example:

>  let tf_minlines = your choice


X Pixmaps (XPM)						*xpm.vim*

xpm.vim creates its syntax items dynamically based upon the contents of the
XPM file.  Thus if you make changes e.g. in the color specification strings,
you have to source it again e.g. with ":set syn=xpm".

To copy a pixel with one of the colors, yank a "pixel" with "yl" and insert it
somewhere else with "P".

Do you want to draw with the mouse?  Try the following:
>   function! GetPixel()
>      let c = getline(line("."))[col(".") - 1]
>      echo c
>      exe "noremap <LeftMouse> <LeftMouse>r".c
>      exe "noremap <LeftDrag>  <LeftMouse>r".c
>   endfunction
>   noremap <RightMouse> <LeftMouse>:call GetPixel()<CR>
>   set guicursor=n:hor20          " to see the color beneath the cursor
This turns the right button into a pipette and the left button into a pen.
It will work with XPM files that have one character per pixel only and you
must not click outside of the pixel strings, but feel free to improve it.

It will look much better with a font in a quadratic cell size, e.g. for X:
>   set guifont=-*-clean-medium-r-*-*-8-*-*-*-*-80-*

==============================================================================
5. Defining a syntax					*:syn-define*

Vim understands three types of syntax items:
1. A keyword.  It can only contain keyword characters, according to the
   'iskeyword' option.  It cannot contain other syntax items.  It will only
   be recognized when it is a complete match (there are no keyword
   characters before or af