https://invisible-island.net/vile/vile-toc
Use Ctrl-D and Ctrl-U to scroll through this help information.
Type Ctrl-O to make this the only window on the screen. Type Ctrl-K to get rid of this window.
First, to leave vile, use any of the following:
To get help (probably just this text), use any of:
:h
:help
^X-h
^A-h
The only vile commands described herein are those not present in vi, or differing greatly from those in vi. There is a section at the bottom describing other differences between vile and vi.
To get a complete list of all commands, type ":show-commands". To get a list of all commands that contain the string "name", type ":apropos name". These lists will show all command synonyms and key sequences that are bound to the same function, along with a short description of the command, and whether it is a motion or operator command.
For a list of motions, type ":describe-motions". Likewise, you can see a list of operators by typing ":describe-operators".
To get information on a specific key-binding or function, use the "describe-key" or "describe-function" commands. You will be asked for a keystroke or function name, and a short description will be shown.
You needn't type full command names -- type a few characters and hit TAB to perform command completion. Hitting a second TAB will pop up a window containing the list of possible completions.
If your screen hops around a lot when you scroll, see the "Note on Scrolling" section near the bottom of this file.
vile holds text in "buffers". Usually, these correspond to a file that you are editing, but not always. For instance, a buffer might be used to display this help text, or to hold the output of a shell command that you have run. Buffers have names, and these usually match the names of the files they contain.
Buffers are sometimes displayed in windows. A buffer may be displayed in more than one window at the same time. There is no such thing as a hidden window. All existing windows are on the screen. There may, however, be hidden buffers, which are not currently associated with any window.
All yank/delete registers (the default unnamed register, the numbered registers ("1-9") that hold line-deletes, and the named registers ("a-z")) are global to the editor, and not attached to any single buffer. Thus you can delete text in one buffer and put it back in another.
Undo operations are attached to a buffer, not a window. Thus if you have two windows to the same buffer, and make a change in one, you can undo it in the other.
vile supports many, many "modes" (aka options), which are thoroughly explained in the section entitled "Editor modes". But do note that this help file makes references to modes before the concept is fully described. It's a chicken and egg problem....
vile is 8-bit clean, allowing it to be used more easily at non-English speaking sites. See the section on "8-Bit Operation" for more information.
To extend the vi command set in vile, two (or three, depending on how you count them) command "prefixes" exist. These keystrokes, in combination with another key, can be bound as a pair to execute any vile function. The default values for these prefixes are
| Key: | Bound to dummy function: |
|---|---|
| ^X Control-X | cntl_x-prefix |
| ^A Control-A | cntl_a-prefix |
| # poundsign | function-prefix |
If you find any of these keys hard to type, or would prefer that they are all control characters (or all non-control), they can be changed by binding a new key to the function listed above. See the section on "Key Rebinding" below. If you do change the values of these keys, most of vile's informational displays (the Binding List, for instance) will reflect these changes. This documentation, of course, will not change.
(The '#' key is used in vi to give terminal independent access to function key bindings. This is also true in vile -- if something is bound to '#2', then it is also probably available with key F2 on your keyboard.)
vile stores buffers in a sorted list. Depending on the setting of the "autobuffer" mode, this list is either sorted in "most-recently-used" order (this is the vile default), or in a fixed order dependent on the order of editing (this is how vi normally does it, and can be attained by turning "autobuffer" off, with "set noautobuffer").
The buffer number may also precede the '_' command. This is necessary when visiting buffers numbered higher than '9'. For example, one would type "13_" to visit buffer 13 in the list.
Use tab (or back-tab if supported) to scroll the list of 9 buffers right/left. Pressing '_' will select the first listed buffer; the 1-9 digits also work as expected when the list is scrolled.
[ See the note under "Differences", below, for comments on vi's use of '_'.]
^X-_1 does the trick (reverts to views "A" and "B"), but _1 simply moves the cursor into B's window, retaining views "C" and "B".
(The previous four commands are useful when comparing two buffers. Mnemonic – think of them as affecting the "A"lternate window.)
If for some reason you can't get your screen set right via a TERM variable, try the ":screen-rows" or ":screen-columns" commands (which take their args (number of rows or columns respectively) before you type the ":").
[ I put the following bindings in my startup file (.vilerc):
bind-key split-current-window ^T ; split into 'T'wo windows
bind-key next-window ^N ; 'N'ext window
bind-key previous-window ^P ; 'P'revious window
Since ^K already 'K'ills a window, and ^O makes it the 'O'nly window, these give more mnemonic, and faster, access to multiple windows. (These would be the default, but ^N, ^P, and ^T have other meanings in real vi (all of which have alternate bindings in vile.) ]
The usual ":e", ":r", ":f", ":w" commands are available, though only ":e!" and ":w!" are available of the "!" options. The command ":w >> filename" appends one file to another. The ":r" command reads the named file in after the current line. To read a file before the first line, use ":0r". File completion works like command completion: using the TAB and '?' keys you can complete or see next character choices. Additionally, on unix hosts, backquotes may be used to invoke a shell command that returns the path of a desired file. For example:
:e `which locks` ; csh looks for script called "locks"
:e `type -path locks` ; bash equivalent
The commands ":ww" and ":wwq" correspond roughly to ":w" and ":wq", but they each write all modified buffers, rather than just the current one. Giving any numeric argument to ":ww" (i.e. "1:ww") will suppress the per-file and "Press return to continue" message. This may be useful when using the command from within a macro.
The write-all-buffers command attempts to write all buffers whether marked "modified" or not.
As in vi, ranges of lines specified by line numbers (including '.', '$', and '%' shorthands) or marks may precede these commands. Unlike vi, search patterns cannot be used as line specifiers.
In addition, two non-"colon" commands have been added:
If a register is specified (e.g. "a^W ) then the command is not an operator, but writes the specified register to the named file.
Anywhere a filename is valid, a command name is also valid, entered in the form "!shell-command". The whole line is handed to the shell, and the read or write operation is done on the command's standard input or output, as appropriate. Thus you can type ":e !date" to edit a copy of today's date.
The ": !cmd" shell escape works pretty much as it does in vi. The command ":!!" will rerun the previous such shell command.
The '!' operator works as a filter, as expected.
In addition, the ^X-! command runs a shell command and captures its output in a specific buffer, called "[Output]". This is almost identical to ":e !cmd", except that in that case the buffer is named according to the command name.
These "output capture" commands are most useful in conjunction with the "error finder", '^X-^X', described below.
Filename completion is performed on words of the shell command in response to a TAB character. To actually include a TAB character in the shell command, escape it with ^V. Command completion is not currently implemented – so, for instance, $PATH is not searched for possible completions to the first word of a command line.
On systems supporting job control, ^Z (or ":stop") will suspend vile.
The "set-environment-variable" (or "setenv") command can be used to export new or changed environment values to spawned programs. (Note that this might or might not affect the operation of vile features that are themselves controlled by environment variables, since those variables may only be checked once at the time that vile is started.)
The :cd and :pwd commands are of course supported. Unlike vi, filenames will track their directory of origin, so you can't simply edit a file in one directory, cd to another, and write it. You must explicitly write to ./filename in the new directory to accomplish this. ":cd -" will return to the previous directory, as it does in some shells. The CDPATH environment variable provides a search path for the :cd command. This variable's path delimiters are host-specific, as follows:
| Unix | colon |
| DOS, OS/2, Win32 | semicolon |
| VMS | comma |
Giving an argument to the ": !" (also called "shell-command" when writing macros) will suppress the "Press return to continue" message after the command runs.
Additional shell-related features are described in the section of this help file entitled "Working in a project hierarchy".
Remember, these are only the new or different commands. The standard vi set should still work.
The vi "global" (":g") command is present. So is the "substitute" (":s") command. These both look pretty different while they're being used than they do in vi, due to the interactive nature of the prompting. And, since the searching is done right after the pattern is entered, there may be a slight delay while you're trying to finish typing your complete command. (If the pattern does not exist, you may not get to finish typing your command at all.) You can use the commands just as you would have in vi, i.e. ":g/oldpat/s//newstring/" will work. But you won't see any of the '/' characters. Try it– you'll get the idea. Line ranges are not possible on ":g", but they are on ":s".
The ":g" command can be followed by any of the "global command" modifiers. Use ":describe-globals" to see the whole list, or simply use name-completion. These are the most commonly used:
For example, ":g/pattern/Put" will insert the contents of the default yank register just above every line containing "pattern". The ":g" command can only be used over the entire file – smaller regions are not permitted.
The ":v" counterpart to ":g" is also implemented – it performs the given command on all lines that don't match the given pattern.
The substitute command can be followed by any of 'g', a digit, or 'p', to do the substitution for all occurrences, the n'th occurrence, or to print the resulting line respectively. You can also add a 'c', and you will be asked to confirm each replacement before it occurs. The text being replaced will be highlighted, and you can answer with 'y', 'n', 'q', or 'a'. 'a' will suppress further prompting, and will do the rest of the replacements.
The ":&" and '&' commands work much as they do in vi, and repeat the last substitution. The '^A-&' command is a new operator (see below), so it can work on regions: for example use '^A-&}' to "repeat the previous substitution over the rest of this paragraph".
The named marks such as "'a" work as they do in vi. vile allows a decimal digit as a mark. It also recognizes special marks for the beginning and end of a selection: '< for the beginning and '> for the end (see the discussion of the quoted motion command).
The regular undo ('u') and line-undo ('U') are available for all commands. They are a little more predictable than their vi counterparts, since they do not share the default yank register for their operation. Also, line-undo ('U') is available until the next change anywhere in the file, rather than until you leave the line.
vile also lets you undo all changes made to a buffer since it was first edited (so-called "infinite undo"). The '^X-u' command will undo changes, one by one (or given a count, several at a time). The '^X-r' command will walk forward, redoing the previously undone changes one by one. A fresh change to the buffer will cause previously undone changes to no longer be redoable. Remember that with key rebinding, you can change your 'u' or 'U' command to be an infinite undo, making it easier to type.
In addition, the '.' command, which normally re-executes the last buffer-modifying command, has special behavior with respect to undo. If the '.' command immediately follows one of the undo commands ('u', '^X-u', or '^X-r'), then it will perform another undo or redo, as appropriate. If there are any intervening commands, then '.' will re-execute the last command prior to the undo. [ This modification to the behavior of "u." does not conflict (much) with traditional use of '.', since by definition, the sequence "u." is (almost) always identical to "uu", and the latter is more easily typed. (Credit goes to the designers of "nvi" for this trick.) (the one case I know of where "u." is not identical to "uu" is when putting back the contents of the numbered registers: the sequence "1pu.u.u.u. would successively insert the contents of "1, "2, "3, "4, and "5, allowing you to choose the "correct" register. This sequence no longer works. You can still put them all back with "1p..... ("1p for screen) and then delete the ones you don't want. ]
The number of changes stored in the undo "history" is controlled by the numeric mode "undolimit". The default history length is 10 – that is, only 10 changes may be undone. Set the undolimit to 0 for truly infinite undo. This can consume a lot of memory. You can turn it completely off (and purge the undo stack) by setting noundoable.
The cursor position after an undo may not always be the same as it would be in vi.
vi has a class of commands known as "operators". Operator commands are always immediately followed by a motion command. The region of text affected by an operator is bounded on one end by the initial position of the cursor, and on the other by the cursor position after the motion is completed. Thus the delete operator ('d') can be followed by the word motion command ('w'), causing the next word to be deleted. The sequence "dG" will delete from the cursor through the end of the file, and "d/junk" will delete to the next occurrence of the string "junk". As a special "honorary" type of motion, operators can all be "stuttered" to affect lines. Thus "dd" deletes one line, "4dd" affects 4 lines, etc.
Most operators affect the region exactly, but some cause only whole lines to be affected. This is usually a function of what sort of motion follows the operator, but can sometimes be affected by the operator itself. The best example of motions having different effects is the 'goto-mark' motions, the ''' and '`' commands. If a mark is set, say mark 'a', with the 'ma' command, then if the command d`a is executed, the exact text between the cursor and the mark will be deleted. If, on the other hand, the d'a command is used, the deleted region will include the lines containing the cursor and the mark in their entirety.
Some operators in vile can be "forced" to affect regions of whole lines, though the motion wouldn't normally imply it, by using the '^X' form of the command. (It's not really forced – it's really a separate operator.) For example, "d%" (assuming you are on a curly brace) will delete a C-style block of code. "^X-d%" will delete that same area, plus anything else on the lines containing the curly-brace endpoints.
Note that some operators always affect whole lines, no matter how the motion is specified. The '!' operator is an example: "!w" will always filter an entire line, and not just a single word.
vile extends this notion of the "shape" of a region by adding the concept of rectangular regions, whose boundaries are delimited by the rectangle whose opposite corners are at the cursor and at the other end of the motion, respectively. See the section "Rectangular regions" below.
The "show-operators" command will show all available operators. The "show-motions" command will show all available motions. Any operator may be followed by any motion.
There are several new operator commands in vile:
The following two commands may not always be present in vile, depending on how it was built:
vile supports vi-style "tags" files.
:ta is_sl<tab>
is completed as "is_slashc" . Pressing RETURN following completion opens a buffer on estruct.h, with the cursor positioned at the first definition of this tagname.
When one of these commands is used, vile will (by default) look for a file named "tags" in the current directory, and load it into a hidden buffer for use during tag searches. This buffer is editable if you wish (":e tags"), but will not appear in the buffer lists. If a buffer named "[Tags 1]" is already available when a tag is first requested, it will be used instead of a file found by searching the tags setting, and of course will remain visible.
Take note that the tag locate and pop commands, by default, move the cursor out of the current window if the target tag is located in one of the editor's other windows. To "pin" all locate and pop actions to the current window, set pin-tagstack mode.
The name of the default tags file may be changed with "set tags" (see "tags" under "Editor modes", below). If multiple filenames are given in the "tags" setting (separated by whitespace), they are searched in order, and placed in buffers named "[Tags 1]", "[Tags 2]", "[Tags 3]", etc.
Tags searched for using '^]' will always be matched exactly. If the ":ta" form of the command is used, tag matches will be exact unless the mode "taglength" is set non-zero, in which case the first tag matching that many characters will be used.
Filenames referred to in tags files are expanded, so environment variables and shell special characters like ~ may be used.
The stack of buffer locations waiting to be "popped" to with the '^T' (or '^X-^]' or ":pop") command may be viewed with the "show-tagstack" command. The "[Tag Stack]" buffer is animated – it will dynamically keep track of current tag references.
Limitations: In a real vi-style tags file, there are three tab separated fields. The first contains the tagname. The second contains the (relative or absolute) filename. Everything after the second tab is an arbitrary ex-mode command. vile is not quite so flexible as regular vi, and only supports a couple of commands in that last "field". It can be a line number, in which case the tag is an absolute index into the file. Or, it can be a search command. If it begins with a '/', the search goes forward. If it begins with a '?', the search goes backward. In either case, the matching delimiter must be the last character on the line in the tags file.
All of this isn't as bad as it sounds, since ctags, the program most people use to generate tags files, does generate exactly this format. (Surprise, surprise.) However, if you attempt to create your own tags files, or have other tools that do so, you should be aware of these limitations.
For further tags usage examples, refer to the section of this help file entitled "Working in a project hierarchy".
delete-empty-lines). This
command differs from delete-blank-lines:
force-empty-lines.force-empty-lines). This uses
the variable $empty-lines as
the size that should be used. Like
delete-empty-lines, this is an operator and can be
used with a range.For example, "^X-!cc -c junk.c" puts all of the compiler output into the buffer named "[Output]".
Repeatedly hitting ^X-^X will position the editor at each error in turn, and will eventually start over again at the top. The buffer searched for "errors" will be the last shell command run, or the buffer named with the "error-buffer" command. The "Entering directory XXX" and "Leaving directory XXX" messages that GNU make puts out with the -w switch are honored, so that files are found with the correct path.
Tip: I use the following macro to quickly grep a source directory for the string under the cursor:
use-register g load-register "^X!egrep -n : *.[chs]^M"
where the ^X and ^M are each single control characters, entered using ^V to escape them. Then I invoke with @g to execute. [NB: this macro won't work with the DOS/VMS/Win32 versions of vile, since ':' doesn't expand to the word under the cursor on those hosts due to conflicts with filename drive/disk delimiters. For those hosts, substitute '&' instead.]
The command parsing is done with regular expressions. Vile compiles these from the buffer [Error Expressions], which are a set of regular expressions with extra embedded information. Unescaped '%' followed by 'V', 'B', 'F', 'L', 'C' or 'T' substitute verb (Entering/Leaving for gmake), buffer (i.e., scratch buffer with a bracketed name), file, line, column and text fields.
The line and column numbers are 1-based, treating tab character as a single column. Use %l and %c, respectively for 0-based values.
The V, B, F, T substitutions are for nonblank fields, which is not always enough, so vile additionally recognizes a range in brackets, e.g.,
^%[^: ]:\s*%L:%T
is compiled as
^\([^: ]\+\):\s*\([0-9]\+\):\(.\+\)
The expressions can be manipulated with scripts:
; example of a macro to add to [Error Expressions]
store-procedure AddError
~local %oldbuffer
setv %oldbuffer=$cbufname
compile-error-expressions
yank-line
edit-file '[Error Expressions]'
unsetl view
goto-beginning-of-file
put-before
unmark
setl view
buffer %oldbuffer
compile-error-expressions
~endm
Use the show-error-expressions command to display the contents of the [Error Expressions] buffer, along with the expanded regular expression and annotation for the substitutions. The result is shown in [Error Patterns].
dq<arrow><arrow><arrow>...<arrow>q
to delete all of the text between the starting point and the final cursor position.
Any motion command can appear in between the two 'q' commands. If used alone, i.e., not in an operator context, then the spanned text is highlighted, and yanked on completion (as well as setting the special named marks '< and '>) as a side effect. The resulting selection can then be manipulated with the ^S pseudo-motion, below. The selection-clear command removes the selection's highlight attributes.
Most motions will select up to but not including their endpoint. The 'e', 'E', 'f', 't', and '%' commands are exceptions to this. If used in an operator context the cursor position may sometimes appear incorrect. This is because operators sometimes change the cursor location internally to force the motion to do the "right" thing, and the 'q' command makes these internal "fudge factors" visible. An example of this is "dq%q" which does the right thing (assuming the cursor is on a '(' to start) but which looks wrong, since the cursor will overshoot the ')' before the second 'q' is typed.
If a mouse is available on a Unix host, whether in an xterm via the "xterm-mouse" setting, or in xvile, then button 1 can be clicked to do the extensions, since it, too, is a motion command. (Of course in xvile or winvile, it is easier to simply "click and drag" – the 'q' command isn't really necessary at all.)
Use the repeat-count to specify types of selection: exact=1 (default), full-line=2, rectangle=3.
^S makes it possible to select any region (including rectangular regions) of text with a mouse, and then apply any vi operator to that region.
| Technique | Applies To |
|---|---|
| selection-clear command | any host |
| left mouse button (LMB) click | winvile |
| click mode line with LMB | win32 host |
| press ESC | winvile |
vile can display more of its internal "state" than traditional vi. Portions of the internal "state" may be viewed using various "show-xxx" commands:
Use a repeat count to show data for the wide locale. The default (no repeat count) shows the narrow locale. Use show-wide-printable to see wide characters past the first 256.
If showchar is set, this also shows a line for the current character in the current buffer, with the character type information for that character.
Use a repeat count to show the data for successive "pages" of 256 characters, e.g., 1 for 256-511, 2 for 512-767, etc.
This uses the same buffer as show-printable. If showchar is set, this also shows a line for the current character in the current buffer, with the character type information for that character.
In addition to the usual "a through "z, and "1 through "9, vile has additional registers.
The register named '<' contains the last few hundred keystrokes that have been typed by the user. The principle use for this is to make it easier to create :map commands based on commands you've already given. [It's also useful sometimes when debugging to be able to see what key sequence led to a problem...]
The register name '.' contains the current selected text in xvile. Also in xvile, the register name ';' is a synonym for the clipboard. Other versions of vile permit use of '.' and ';' as supplemental register storage.
The register name '"' (" is double-quote) is a synonym for the default unnamed register, which is also sometimes referred to as register 0.
Many responses to vile prompts need not be typed in their entirety. vile can complete the response for you. This applies to command names, file names, vile modes, vile variables, tags, buffers, and the "terminal characters".
To invoke vile completion, type a few characters and hit TAB (or your current "name-complete" terminal character). Hitting it a second time will pop up a window containing the list of possible completions. If there are more completions than will fit in the window, hitting further TAB characters will cause that window to scroll through the choices. The window will go away when the current command is finished.
An older form of completion is also supported:
You can also type a question mark (or the current
"test-completions" terminal character) to display a list of the
characters that you would have to type to complete the command.
For example, to complete the "unmark" or "unmap" commands:
:unm? – you type
:unm{a}[pr] – you see
This style of completion-display shows curly braces around the string that will be supplied by pressing TAB, and square brackets around characters that you must type to make the command unique.
vile will understand your terminal's arrow keys, as long as they are described correctly in the termcap/terminfo database. The keys are interpreted as function keys, and are by default bound to the up, down, left, and right screen motions. These bindings are honored in insert mode as well as command mode.
Just as the regions defined by vi's commands and motions can either be "exact", or encompass "full lines", regions in vile can in addition be "rectangular". The easiest way to use a rectangular region is with the '\' motion, which, like '`' and ''', goes to a named mark. The region it describes, however, is "rectangular" (instead of "exact" or "full line"). The following operators know how to correctly act on rectangular regions:
Note that because it is sometimes hard to manipulate rectangles containing or bordering on tab characters, currently (for some operations) vile "detabs" the region being operated on before commencing, and re-entabs the lines again after the operation. The re-entabing is limited to leading whitespace, and of course is suppressed if "notabinsert" mode is set. [ This misfeature is arguably a bug, and may be fixed. In the meantime, you've been warned. ]
Modes come in various flavors and types and constitute the editor's primary configuration mechanism. vile supports these mode types:
boolean enum int string
The value of a mode is specified via "set" or "setl" (the latter command only affects buffer modes, as described below). Mode values may be cleared with "unset" (or "unsetl" for buffer modes), as well as other idioms described later. Clearing a mode, by the way, is a fancy way of saying that its value is set to 0 or "", the latter for string types. When an enum mode is cleared, vile selects whichever enum constant is assigned the internal (read compiled) value of 0. Some concrete examples:
| Technique | Applies To | |
|---|---|---|
| mode type | mode name | example usage |
| boolean | autoindent | set autoindent |
| enum | visual-matches | set visual-matches=reverse |
| int | fillcol | set fillcol=75 |
| string | tags | set tags="../tags tags" |
These modes are not directly associated with buffers, windows, or languages. Consequently, a universal mode affects the editor under all relevant operating conditions.
To set/modify a universal mode, use the "set" command. Startup file examples:
set vtflash=normal unset flash ; or set noflash set errorbells
Since the set command (within a startup file) accepts multiple modes, this oneliner is equivalent:
set vtflash=normal noflash errorbells
To clear a universal mode use one of these idioms:
set no<modename> unset <modename> setno <modename>
For completeness sake, note that the "local" version of the set/unset commands ("setl"/"unsetl") do not make sense (and elicit no effect) when used with universal modes.
These modes are inherited from a set of "global" buffer modes, but bound to a specific buffer once a "local" value is independently established. To set and reset local modes, use "setl", "unsetl", or "setlno". An actual example is useful for illustration purposes.
When vile is started, the global value of "view" mode is unset by default (i.e., false) and all newly visited buffers are editable. But suppose I edited the file "precious.cpp", which I did not want to modify. There are two approaches that could be taken:
$ vile :set view ; enable view mode globally :e precious.cpp ; edited in "view" mode :e other.cpp ; ditto
or
$ vile :e precious.cpp ; initially edited in "noview" mode :setl view ; "view" mode now bound to precious.cpp :e other.cpp ; edited in "noview" mode
In the first approach, view mode is enabled globally and consequently affects all existing buffers and all subsequently created buffers. This solution works for the stated goal, but makes it impossible to modify any other buffers. The second approach affects only the targeted file.
Similar to buffer modes, window modes are bound to a specific window once a local value is independently established. These modes are set/cleared with the same commands as buffer modes.
Until the subject of syntax coloring is described, it's not very useful to discuss majormodes. So, in the listing of modes below, skip over anything tagged with (M). But don't fret, these modes are described separately in the topic entitled "Majormodes".
To display modes, use "setall", "modes", "set all", or simply
"set". vile displays all of the current mode values in the
[Settings] buffer.
vile shows local mode values only if they differ from the global values, whether they have been independently set or not.
To show just the local mode values that differ from the global values, use show-local-modes.
Shown next is a listing of vile's various modes. Synonyms, if they exist, are shown in parentheses and a trailing U, B, W, or M indicates whether the mode is universal, buffer, window or major.
The animated buffers include:
[Binding List] [Buffer List] [Color Palette] [Color Schemes] [Command-Bindings] [Error Expressions] [Error Patterns] [Extra Colors] [Insert-Bindings] [Major Modes] [Map Sequences] [Map! Sequences] [Named Marks] [Printable Chars] [Registers] [Select-Bindings] [Settings] [Tag Stack] [Terminal Characters] [Variables]
Turning off "animated" is rarely necessary: the capability is present mostly as a debugging aid. (B)
"auto" "none" (default) "utf-8" "le-assumed" "be-assumed" "utf-16le" "utf-16be" "utf-32le" "utf-32be"
The "auto" setting tells vile to set the buffer's byteorder-mark value based on whatever the file-encoding happens to be.
The default value is "none", which is slightly different, telling it to accept byteorder-mark values as in "auto", but not to write them for buffers which have no explicit byteorder mark set.
The "utf-XXX" values are explicit settings, which override the auto/none logic. Use "le-assumed" or "be-assumed" for cases where the platform's preferred byteorder is known, and where byteorder marks may be absent from files, e.g., with Windows. (B)
The default value is "current". (U)
The prompt will occur only once, unless the file changes again, in which case the warning will be repeated. The warning will be repeated in any case if the file is being written. Invoking a shell, or suspending/restarting vile, will cause all visible buffers (those currently in windows) to have their times checked immediately. A file is considered "changed" if its modification time changes, or, under UNIX, if it is replaced entirely, resulting in a different inode number. (The "unique-buffers" mode must be active to enable the latter behavior.) (B)
as well as any character that may be listed in fence-pairs. If it is listed in cindent-chars as well, the left-character of a pair causes the next line to be indented more, and the right-character causes the next line to be indented less. (B)
The percent-crlf mode tells vile how many lines in the buffer must have CR/LF endings for it to automatically treat a buffer in this manner.
On output, when writing a buffer with local dos mode set, all lines will be terminated with CR/LF pairs, rather than the usual single LF.
When buffers representing non-existent files are created
they will inherit the line-style of the operating system
(LF-only on UNIX and VMS, CRLF-style on DOS derivatives)
regardless of the global setting of dos mode. However, even
this can be overridden using the -u and
-U options, which preset the
$system-crlf variable used to initialize dos
mode.
Setting dos mode makes editing binary files unreliable.
The global value for this mode is set on by default in DOS versions of vile, and should therefore be turned off if doing binary editing. (B)
"8bit" "ascii" "auto" "locale" (default) "utf-16" "utf-32" "utf-8"
The "auto" setting tells vile to determine the encoding by inspecting the buffer contents. The "locale" setting tells vile to assume that the buffer contents are in the current locale's encoding. The "8bit" setting corresponds to the 8-bit locale support used since 9.3i (20021223). (B)
The choices are
On UNIX, glob can be set to be a pipe command that will expand more wildcards. The default value of glob on UNIX is "!echo %s", which should provide globbing that matches that of your shell. If set to a command that will separate filenames with newlines or nulls rather than spaces, then filenames containing spaces may be more easily edited. ("!/bin/ls -d %s" is one possibility, "!glob %s" is another if you use csh.) (U).
\<[[:ident:]]\+\>
This is a buffer mode. (B)
See the discussion of insert mode, in particular
describe-insmode-bindings describe-insmode-key
emacs
nvi
vi
where "emacs" is used to denote vi-like-emacs. The setting for "vi" matches the behavior of vi on AIX, HPUX and Solaris. Here are some examples to compare, where "top" and "bot" refer to the top/bottom of the range, and "n/c" indicates that the cursor does not move:
| command | vile | nvi | solaris |
|---|---|---|---|
| :%> | top | n/c | bot |
| :%s/^/ / | bot | bot | bot |
| :5,10> | 5 | 10 | 10 |
| :.,.+5> | n/c | n/c | +5 |
| :.-5,.+5> | -5 | n/c | +5 |
| :-5,+5> | -5 | n/c | +5 |
| :-5,+5s/^/ / | +5 | +5 | +5 |
linewrap mode is set, add blanks in the
display to avoid splitting "words" (any nonblank text).
(W)"vi:" "vile:"
or (depending on the configuration):
"xvile:" "winvile:"
After that, either a "set" command terminated by a colon, e.g.,
vile:txtmode:
or one or more mode assignments, treating colons as a whitespace separator, e.g, these are equivalent,
vile:ts=4 nu vile:ts=4:nu
The modelines at the top of the buffer are processed first (working forward from the top), then the ones at the bottom (working backward from the end). If the buffer is small enough, the available modelines could overlap; but the program interprets each line at most once.
This is a buffer mode, enabling its use in majormodes. (B)
\<[[:file:]]\+\>
This is a buffer mode. (B)
When enabled with either "immediate" or "delayed", vile pops up the [Completions] buffer showing choices for filename and command completion in response to a TAB. "immediate" will force the buffer to be popped up immediately if no progress is made in forming a completion. "delayed" will cause vile to wait until TAB is pressed a second time before popping up the completion choices. (U)
When enabled with either "bottom" or "top", vile pops up buffers showing buffers, completions and messages below or above the current window. "notdot" is the default behaviour, the popup window will appear away from the cursor line.
When reading from a file, vile can determine the file format automatically, and set a local value for this mode. When reading from a pipe, it uses the global value of recordseparator to decide how to split lines. Files created within vile do not automatically have a local recordseparator mode; they inherit the global mode setting. The commands
set-rs-cr set-rs-lf or set-unix-mode set-rs-crlf or set-dos-mode
are aliases which set the corresponding local mode values of recordseparator. Set the recordseparator on a given buffer to control how it is written. (B)
<current buffer name> - <editor name>
The swapped order is especially useful under limited screen real estate conditions. (U)
The '=' command can be used to clear this sort of highlighting, until the next search is done for a different pattern. Note that setting this mode can significantly slow down the editor's operation when complex or frequently occurring patterns are used, since vile will need to scan the entire buffer for matches on any change to the buffer. (B)
| Mode Value | Mode Semantics |
|---|---|
| off | feature disabled (default) |
| reverse | on err -> switch screen to normal then reverse video. |
| normal | on err -> switch screen to reverse then normal video. |
As is true with "flash" mode, no audible or visible indication will occur at all if "errorbells" mode is not set on. (U)
A value of 5 and an 80 column screen will result in 75 character lines. This mode is different from the "wrapwords" mode (below) which uses the "fillcol" setting as its target column. The two modes probably should not both be used at once. (B)
vile allows input, manipulation, and display of all 256 possible byte-wide characters. Wide characters are supported, depending on the device type and your locale settings.
By default, 8-bit characters with the high bit set (decimal value 128 or greater) will display as hexadecimal (or octal; see "unprintable-as-octal" above) sequences, e.g. \xA5. A range of characters which should display as themselves (that is, characters understood by the user's display terminal) may be given using the "printing-low" and "printing-high" settings (see above). Useful values for these settings are 160 and 255, which correspond to the printable range of the ISO-Latin-1 character set.
If your locale (e.g., the LANG or LC_CTYPE environment variable on a POSIX platform) is configured properly, the "printing-low" and "printing-high" settings are not needed. vile initializes its character type tables based on the system. You can make finer adjustments to those tables as described in "Character Classes".
If your terminal (and locale) are set up to support UTF-8, vile can display files which use that encoding. It can also display UTF-16 and UTF-32 files using UTF-8. When the terminal/locale do not support UTF-8 vile displays the wide characters as hexadecimal codes, e.g., \u1234. Even when vile can display wide characters, you can force it to display the hexadecimal codes with the "unicode-as-hex" mode.
See UTF-8 Support versus Driver in config.doc for an overview of the terminal drivers.
If your terminal and locale are not set up to support UTF-8, vile displays UTF-8 codes that would map to Latin-1 (8-bit) values with a "\?" rather than "\x" prefix, to distinguish them from ordinary 8-bit values. It will also display this form for bytes found in UTF-8 files that cannot be decoded as UTF-8.
There are basically three ways of getting 8-bit characters into a vile buffer:
If you start vile in a locale that uses UTF-8 encoding, vile will check if there is a corresponding 8-bit encoding by stripping the UTF-8 suffix from the locale name, e.g., "en_US.UTF-8" to "en_US". When reading characters from the keyboard, it will map 8-bit codes to the 8-bit locale when editing a buffer whose file-encoding is "8bit" or "ascii".
Wide (Unicode) values can be entered in a similar fashion, though they are stored as more than one byte:
If the current buffer's "file-encoding" mode is set to one of the Unicode flavors (utf-8, utf-16 or utf-32), vile will display the value as a wide character. Otherwise it will show the bytes of the corresponding UTF-8 encoding.
Users who have no need to enter 8-bit text may want access to the meta-bound functions while in insert mode as well as command mode. The mode "meta-insert-bindings" controls whether functions bound to meta-keys (characters with the high bit set) are executed only in command mode, or in both command and insert modes. In either case, if a character is not bound to a function, then it will be self-inserting when in insert mode. (To bind to a meta key in the .vilerc file, one may specify it as itself, or in hexadecimal or octal, or with the shorthand 'M-c' where c is the corresponding character without the high bit set.
(Although it is possible to edit and view all 256 characters, it is currently impossible to search for a string that contains the NULL character, since this is used internally to terminate the search string.)
You may scroll through the list of previous replies to the :-prompt by using the up- or down-arrow special keys on your keyboard (if your configuration supports it).
Vile prompts for commands in parts, and stores a copy of the complete command in the [History] buffer. For example, you may type
:g/help/p
and vile will prompt for the parts after each delimiter, e.g.,
global pattern: help action to perform on each matching line: p
The [History] buffer, shown with "show-history" will store
g/help/p
At each prompt, using the up/down arrows will tell vile to display the corresponding result for the "same" command. If [History] contains
g/take/g g/help/p
then the up/down arrows will show "take" or "help", skipping commands which do not begin with "g/".
The minibuffer (i.e., the last line on the screen, aka the :-prompt) can be edited using arrow keys, the delete character, or by toggling to vi-mode with the ^G (mini-edit) character. In mini-edit mode, you may use commands that do not move the cursor to a different line, as well as the following editing commands: i, a, I, A.
Vile treats the minibuffer specially. Completed lines are written to the history buffer. When scrolling up/down in the command history, vile displays the data that correspond to the command which you have entered, e.g., a :set command will display the variables entered for preceding :set commands.
As in vi, the % and # characters typed while responding to a prompt will expand to the current or "alternate" filename.
Also as in vi, the ~ character will expand to be the previous replacement pattern when entering either a replacement or search pattern,
In addition, the colon character (":") expands at most prompts to be the identifier name under the cursor.
Expansion of ! to the last command run is implemented, but only when a shell command is being entered.
Any of these expansions can be suppressed by prefixing with a '\'.
The "show-printable" command shows a table of the characters and their classes, e.g., printable, punctuation, etc.
You may modify the characters in (or corresponding to) the narrow local in this table by setting or unsetting a given class for a range of characters. The commands which do this are "set-char-class" and "delete-char-class" or "unset-char-class".
These commands expect the class name and a regular expression which defines a range of characters. The class names (short to allow "show-printable" to show everything in 80 columns) are
| Short | Long Description |
|---|---|
| arg | ex-style line range: 1,$ or 13,15 or % etc. |
| ctl | [:cntrl:] control character |
| del | delete/backspace |
| fn | fence character, e.g., "{" or "}" |
| id | [:ident:] normal identifier, used for word boundaries |
| lwr | [:lower:] lowercase, e.g., "a" |
| nsp | [:graph:] nonspace |
| num | [:digit:] digit, e.g., "0" |
| path | [:file:] file/path name |
| prn | [:print:] printable |
| pun | [:punct:] punctuation |
| qid | qualified identifiers, used in tags parsing |
| sh | may appear in shell/pipe |
| sp | [:blank:] space |
| tmp | legal in scratch-buffer names |
| upr | [:upper:] uppercase, e.g., "A" |
| wld | shell wildcard, e.g., "*" |
You can also reset the table to its initial state using "reset-char-classes".
There is a key rebinding facility (if vile is built to include it), which is invoked as follows. One must know the "english" name for the command being rebound. Use ":show-commands" or ":apropos string" to find english names containing "string". Then use the command:
:bind-key <englishname> <keyseq>
where keyseq is the exact keyboard sequence (i.e. single character, or '^X', '^A', or '#' followed by a single character) to which the command should be bound. In a .vilerc file, keyseq can be either the literal sequence, or the printable representation of the sequence, e.g. ^A-a or ^X-S. (A summary of how key-sequences can be represented appears at the end of this section.)
For configurations that permit it (X and win32, not termcap/terminfo), you may also specify a key modifier, i.e., "alt+", "ctrl+" or "shift+". The modifier follows the ^A or ^X prefix, e.g.,
shift+#6
for shifted function-key 6.
Commands can also be bound to meta keys, which are regular ASCII characters with the eighth bit (0x80) bit set. The "printable" form for these keys is 'M-c'.
Commands bound to '#-c' or 'FN-c' key sequences are usually also available by using the function keys on the terminal. Thus the up-arrow function key can be bound to as '#-A' or 'FN-A'. Use show-key-names to see a complete list of these key sequences.
Even the ^A and ^X prefix characters can be rebound, using the dummy functions "cntl_a-prefix" and "cntl_x-prefix", and the '#' key itself can be rebound – it is represented by the command name "function-prefix".
Examples: To cause the / and ? commands to perform incremental searches, use:
bind-key incremental-search /
bind-key reverse-incremental-search ?
To make ^N and ^P switch windows instead of cause motion by lines, try:
bind-key next-window ^N
bind-key previous-window ^P
To cause the space bar to move forward by pages, as in the "more" command, use:
bind-key next-page \s
(Space and tab can be represented with: "\s" and "\t".)
Note that when interactive, ^A and ^X are typed using the control key. In a file, however, they can be either a caret (^) followed by a letter, or the literal control key. In the latter case you would not use the '-' separator. So ^A-x as four distinct characters could also be entered as ^Ax, which would only be two characters.
Characters can be entered in hexadecimal or octal as well, in the form 0xNN, where NN is exactly two hexadecimal digits. If you know the hexadecimal value for a key, you can bind to it like:
bind-key next-window ^A-\x14
or
bind-key next-window #-\213
The sequence 'M-', represents a "meta-key", or a "meta" character. It is equivalent to setting the high bit of the following character, so 'M-e' is has the value of (0x80|0x65), or 0xe5.
Function and meta-key bindings are available in insert mode, as well as in command mode. (But only via either the "meta bit" or 'FN' sequence form – the '#' prefix will not work in insert mode.) There are four key binding tables:
bind-key describe-all-keys describe-bindings describe-key unbind-key
bind-cmdmode-key describe-all-cmdmode-keys describe-cmdmode-key show-cmdmode-bindings unbind-cmdmode-key
bind-insmode-key describe-all-insmode-keys describe-insmode-bindings describe-insmode-key unbind-insmode-key
bind-selmode-key describe-all-selmode-keys describe-selmode-bindings describe-selmode-key unbind-selmode-key
The "describe-all-*keys" commands differ from the display-commands in each group. They show for each of the 256 character codes which normal (unmodified) or ^A/^X (modified) keys are bound to a given function. Use a repeat count before those commands to show data for all 256 codes.
The following macro will work correctly in both command and insert modes. Note that you must specify the insert mode (insmode) binding separately; default bindings are not inherited automatically because they may conflict with the bindings used for exiting or modifying text within insert mode.
store-procedure begin-errtext
insert-string "fprintf(stderr, \""
set-named-mark z
insert-string "\\n\");\n"
goto-named-mark-exact z
; enter insert mode if we weren't already there
~if &seq $mode "command"
insert-chars
~endif
~endm
; bind to function key 5
bind-key begin-errtext FN-5
bind-insmode-key begin-errtext FN-5
; also bind to meta-A
bind-key begin-errtext M-A
bind-insmode-key begin-errtext M-A
Actually the "meta-insert-bindings" setting controls whether meta-keys will have their bound effect when in insert mode. If this setting is not on (or if the meta-key is not bound to any function) then the key's value will simply be inserted into the buffer.
To summarize, a key-sequence being bound to is specified with:
^A- (three chars)
^X- (three chars)
^A (one char)
^X (one char)
#- (two chars) or
FN- (three chars)
M- (two chars)
(this is the same as with specifying a character in that has
the high bit set)
C (one char)
^C (one char)
^C (two chars)
\NNN (max of four chars, where NNN are octal digits)
\xNN (max of four chars, where NN are hex digits)
\n,\r,\t,\b,\f,\a (two chars each, usual meanings)
\e (two chars, means ESC)
\s (two chars, means SPACE)
(The "one char" control character entries in the above table are represented in this help file as two printable characters, to ensure they are not deleted by mailers or file transfer programs.)
When you bind to a function key, you will see its value printed as a 'poundsign' sequence. And, if you wish to :map a function key, you will need to use its poundsign sequence. This is explained more fully below.
The list of function key labels, along with their "vile name", are as follows:
| Usual Label | Vile name | Usual Label | Vile name |
|---|---|---|---|
| Up-arrow | #A | Home | #H |
| Down-arrow | #B | End | #E |
| Left-arrow | #D | Insert | #i |
| Right-arrow | #C | Delete | #d |
| Prior (PageUp) | #p | Find | #f |
| Next (PageDown) | #n | Select | #s |
| Help | #? | Menu | #m |
| F1 | #1 | F12 | #@ |
| F2 | #2 | F13 | ## |
| F3 | #3 | F14 | #$ |
| F4 | #4 | F15 | #% |
| F5 | #5 | F16 | #^ |
| F6 | #6 | F17 | #& |
| F7 | #7 | F18 | #* |
| F8 | #8 | F19 | #( |
| F9 | #9 | F20 | #) |
| F10 | #0 | F11 | #! |
| KeyPad_F1 | #P | KeyPad_F3 | #R |
| KeyPad_F2 | #Q | KeyPad_F4 | #S |
In addition, #M, #t, and #T are used internally to support mouse operations in an xterm. To undo the relationship between a "system-defined" function key and the poundsign sequence it produces, use ":unmap-system-chars".
The vi "map" and "map!" commands are implemented in vile. As in vi, mapping works best if the character sequence being bound corresponds to pressing a single key. Multiple key sequences will work as long as the next key in the sequence is pressed within a specified number of milliseconds. The value of "timeoutlen" is used for system-defined character sequences, i.e. function keys. User defined sequences will use this too, unless the value of "timeoutlen-user" is non-zero, in which case this value will be used instead.
Because "map" and "map!" may be used to remap arbitrary sequences, these sequences must be entered literally, i.e, the syntax for key sequences as listed above will not work for "map" and "map!". To enter control characters into a .vilerc file, use the ^V escaping mechanism. A map command entered from the command line will require fewer characters be escaped with ^V.
To provide a relatively portable way of specifying function key mappings, vile will reapply mapping to the result of a system-defined map. System function keys are mapped to "poundsign" sequences, like '#1' for function key 1, and '#B' for the down-arrow key. The remapping allows one to put
map #1 <some-user-map-sequence>
in the .vilerc file, and have the user-sequence executed when the system F1 key is pressed. (Otherwise the terminal-specific sequence would have to appear in the .vilerc.) See the section on "Function Keys" above for a full list.
The "remap" option controls whether the successfully mapped result of a map is reevaluated for more mapping matches. The "noremap" (and "noremap!") variants of the map commands will force that particular mapping to be applied without subsequent remapping, regardless of the current setting of the global "remap" setting.
Since key sequences starting the '^X', '^A', or '#' prefixes are normally expected to act as a unit, no remapping is done on characters that follow such prefixes. For instance, this keeps a map like:
:map h ihello<ESC>
from breaking the '^X-h' command.
Long running loops caused by recursive :map definitions are detected and assumed to be infinite. When such a loop is detected, execution is aborted. Turning off the "remap" option, or doing some of the maps with the ":noremap/:noremap!" form of the map commands will eliminate most such loops.
vile normally duplicates real vi's behavior (but not vim's) in that the first character of the sequence being mapped to is not subject to recursive (map) evaluation. Assuming "remap" is on, pressing 'j' when ":map j jh" is in effect will not cause an infinite loop, whereas ":map j hj" will cause such a loop. Setting the "remapfirst" option will allow this sort of remapping (and will cause an infinite loops for both examples).
The "maplonger" option controls whether the longer or shorter of two "nested" map strings will be favored by the editor. That is, if both "foo" and "foobar" are mapped (to presumably different values), then with "maplonger" set, vile will not expand "foo" until it is sure (either because the next character is not 'b', or a timeout has expired) that "foobar" will not be seen. Real vi will always expand "foo" immediately, and this is the default behavior. Though not particularly recommended, the "maplonger" mechanism even permits the following types of mappings:
:map z j
:map zz k
When 'z' is pressed by itself it will cause vile to move down one line (assuming j has not been rebound or remapped). But if 'z' is pressed twice rapidly (enough) in succession, vile will move to the previous line.
The left hand side of a map[!] definition may contain the usual backslash escapes: \n, \r, \t, \b, \f, \a (^G), \e (ESC), \s (SPACE), \xNN (hexadecimal), \NNN (octal). The right hand side is taken exactly literally, so special characters must be expressed as themselves.
The current set of mappings or "map!"ings may be viewed with the commands ":map<cr>" (or ":show-mapped-chars") or ":map!<cr>" (or ":show-mapped!-chars").
The system-defined maps, representing the function keys, may be shown with ":show-system-mapped-chars".
To undo a mapping, use "unmap", "unmap!", or "unmap-system-chars".
The "abbr" command is also present in vile. It is similar to, but slightly different than, "map!". Whereas "map!" examines characters as they are typed, continuously looking for a match against the stored translation strings, the "abbr" command examines them after they are already in the buffer, and is more sensitive to their surrounding context.
First, abbreviations are never expanded unless followed by non-"word" characters. In addition, abbreviations which begin like a "word" (i.e. with letters, digits, or the '_' character) are not expanded if they immediately follow another "word" character – they must follow whitespace or punctuation or the beginning of the line. Likewise, abbreviations that begin with a punctuation character are not detected within more punctuation – they must follow whitespace or a "word", or the beginning of the line.
If the "backspacelimit" setting is set (and it is, by default), then characters not inserted during the current insertion command are not considered in the above comparisons – the start of the current insertion behaves much like the beginning of line in that case.
Abbreviations are never recursive.
vile is more lenient than vi regarding what is a valid abbreviation. vi insists that an abbreviation be all "word" characters, or be all "non-word" characters, except for the last character, which must be a "word" character. vile allows anything at all to be abbreviated, only enforcing the expansion rules mentioned above.
To undo an abbreviation, use "unabbreviate".
In addition to the above binding mechanism for vile commands, other keystrokes to the editor are rebindable using the "set-terminal" command. These keystrokes are mostly derived directly from the user's tty settings on entering the editor, but there are a couple of additions related to command and filename completion.
The values of these characters can be shown with the "show-terminal" command, and can be changed with the "set-terminal" command.
| Name | Default value | Typical value |
|---|---|---|
| backspace | from tty settings | (DEL or ^H) |
| interrupt | from tty settings | (^C or DEL) |
| line-kill | from tty settings | (^U or @) |
| mini-edit | (^G) | |
| name-complete | <tab> | |
| quote-next | from tty settings | (^V) |
| start-output | from tty settings | (^Q) |
| stop-output | from tty settings | (^S) |
| suspend | from tty settings | (^Z) |
| test-completions | ? | |
| word-kill | from tty settings | (^W) |
Historically, the flow of data between the computing host and the user's terminal was throttled through the use of special characters in the input stream, known as XON and XOFF (whose values are ^Q and ^S respectively). Most modern systems do not need these characters, and regulate the flow in an "out-of-band" manner. The terminal device driver, however, is usually still set up with software flow control enabled, to allow the user to manually start and stop output with the ^S and ^Q characters.
vile normally resets the driver to allow the ^S and ^Q characters to be bound to commands, since most systems no longer need software flow control, and since there is usually no reason for a user to wish to suspend output when running vile. Some older devices (usually older slower terminals), however, still need to be able to automatically control the data flow by generating ^S/^Q without the user's intervention.
To accommodate these situations, the "flow-control-enable" command will reset the terminal driver to its original state. Software flow-control will be re-enabled, and commands bound only to the ^S and ^Q characters will be inaccessible. The characters affected in this way may be seen with the "show-terminal-chars" command, where they will appear as the "start/stop-output" characters. The action of the "flow-control-enable" command will be reversed if it is given any argument.
The first type of macro in vile is for temporary, quick macro usage, and lets you record a set of keystrokes as you execute vile commands. You can then replay those keystrokes with a single key.
The vi '@' command is present as well, and can be used to execute the contents of a named register as if it were entered at the keyboard. To make this more useful, the "load-register" command will allow preloading a named register, from .vilerc file. For example:
use-register a load-register ihello^[
will load register 'a' with a command to insert the word "hello". (The ^[ should be a real ESC character, entered by preceding it with ^V.) A better example, is this:
use-register w load-register ":!chmod +w %^M:w^M"
which makes the current file writable and writes it. (Again, use ^V to get the CR characters into the .vilerc file.)
[ Note 1: the information presented in this section of the help file is a subset of "doc/macros.doc", which is supplied with the vile source code. macros.doc is the authoritative reference manual for the editor's macro language.
Note 2: the language features/directives described below are not limited solely to use within macros. These directives are often used within a startup/command file to configure the editor, load registers, etc. ]
vile can also be extended by defining macros and optionally binding the execution of those macros to key sequences. For instance, if the following lines appear in a .vilerc file:
1 store-macro
5 delete-til next-word
~endm
bind-key execute-macro-1 ^A-1
then when ^A-1 is executed, 5 words will be deleted. The "-til" suffix on an englishname denotes that it is a vi operator style command, and expects to be followed by a motion command. Also,
1 store-macro
5 delete-til lines
~endm
would be the equivalent of "5dd" since the word "lines" represents the stuttered 'dd' style of operation. More examples are given throughout this help file.
Macros come in two flavors: named and numbered. The syntax and advantages of each format are discussed next.
The numbered macro syntax looks like so:
<number> store-macro
<language element>
...
<language element>
~endm
A numbered macro is executed using this command:
execute-macro-<number>
To bind a keystroke to this macro, use this command:
bind-key execute-macro-<number> <keystroke>
The only advantage of numbered macros over named macros is that the former do not share the same namespace as vile's commands. This attribute can be advantageous when creating macros recalled solely via key bindings.
Note that numbered macros are allocated from a fixed pool (default is 40 macros). This fixed limit can be changed during the editor's configuration. Given their fixed allocation and the fact that their strictly numeric "names" don't facilitate easy recall, numbered macros are not used that much anymore.
A named macro, aka "stored procedure", uses this syntax:
store-procedure <unique-name>
<language element>
...
<language element>
~endm
where:
A stored procedure is executed by simply referencing its name. To bind a keystroke to this macro, use this command:
bind-key <unique-name> <keystroke>
Here's a trivial example:
store-procedure write-msg-tst
write-message "this is a test macro"
~endm
bind-key write-msg-tst #h
Two mechanisms now exist for executing this macro:
:write-msg-tst
Note that named macros may also include parameters and a help string, each of which are described in doc/macros.doc.
These are defined using the store-operator command, and accept no arguments. Otherwise they are much like other named macros. These macros setup parameters and perform special processing wrapped around one of vile's built-in operators. Here is an example:
store-operator fmt
$cmd-count filter-til $cmd-motion 'fmt -w50 -'
~endm
In the example, the combination of $cmd-count and $cmd-motion (passed into the macro) act as the "real" operator's associated motion.
Macros may incorporate any of the editor's built-in commands, directives (e.g., ~if, ~else), any previously defined named or numbered macro, functions (e.g., &error, &sequal), and variables.
There are some built-in variables that can be used in macros to gain access to parts of vile status, and parts of the current buffer. Built-in variables are accessed by name, prefixed with the '$' character. There are two types of built-in variables (the so-called "state" variables, and mode values). The state variables are: shown in the table below.
You can also show a summary using the "describe-state-variables" command:
| Name | Description | ||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| $_ | most-recent macro $return value | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $abufname | alternate buffer name (i.e. last visited) (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $autocolor-hook | name of the hook that runs when autocolor is enabled | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $bchars | number of characters in current buffer (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $bchanged | true if current buffer is modified (boolean) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $bflags |
status flags for current buffer (read only)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| $blines | number of lines in current buffer (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $brightness | RGB levels for gray, normal, bright in the 0-255 range (winvile version only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $buf-fname-expr | combined buffer+fname expression (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $buffer-hook | name of procedure to run when switching to a buffer | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $bufname | current buffer-name under the cursor. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $bwindows | number of windows open on current buffer(read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $cbufname | current buffer name | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $cdpath | editor's copy of the $CDPATH env var (read/write) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $cd-hook | name of procedure to run when changing directories | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $cfgopts |
comma-delimited list of "interesting" compiled options
(read only).
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
| $cfilname | current file name | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $char | character under the cursor | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $cmd-count | repeat-counter for the current macro (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $cmd-encoding | character set to use for minibuffer | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $cmd-motion | motion for the current operator (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $cryptkey | encryption key (write only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $curchar | character offset in file | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $curcol | current column position of cursor | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $curline | current line in file | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $cwd | current directory | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $cwline | line offset in current window | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $debug | macro debugging – set true for line by line tracing | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $directory | controls location of temp-files (unused) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $discmd | display commands on command line (boolean) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $disinp | display command line input characters (boolean) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $empty-lines | parameter for force-empty-lines command | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $encoding | character set associated with locale (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $end-of-cmd | true if user ended the cmd with <cr> | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $error-buffer | buffer name assigned to the error-buffer | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $error-expr | regular expression that matched the error-buffer | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $error-match | text that matched the error-buffer | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $error-tabstop | tabstop to use with error-buffer for %C | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $exec-path | where to find vile (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $exec-suffix | suffix, if any, for execable programs (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $exit-hook | name of procedure to run when quitting | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $favorites | path to favorites folder (win32 only) (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $fchanged | true if file for current buffer is modified (boolean) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $fence-limit | iteration limit for complex fences | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $filename-expr | actual pattern for %F in [Error Expressions] | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $filter-list | list of builtin-filters (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $findpath | editor's copy of the $VILE_FINDPATH env var (read/write) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $find-cmd | last spawned find command (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $font | current font name (X11/winvile versions only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $forward-search | search direction, true=forward | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $get-at-dot | ensure that "identifier-like" matching includes current editing position. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $get-it-all | match entire "identifier-like" word under the cursor. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $get-length | sets length of "identifier-like" word as side-effect. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $get-offset | sets offset of "identifier-like" word as side-effect. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $helpfile | $VILE_HELP_FILE env var or "vile.hlp" (read/write) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $iconname | current icon name (X11 version only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $identifier | current "identifier-like" word under the cursor. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $kbd-encoding | keyboard encoding | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $kbd-macro | the keyboard macro, see ^X-( ^X-) (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $kill | some of the kill register (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $kill-limit | maximum length for $kill | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $kill-size | length of the kill register (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $lastkey | last keyboard char struck | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $latin1-expr | pattern to match locales using ISO-8859-1 in case they are not installed | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $lcols | length of current line, in columns (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $libdir-path | appended to $PATH when running filters | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $line | text of current line starting with cursor | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $llength | length of current line (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $locale | locale, which determines character type (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $look-in-cwd | true if startup files are sought in the current directory
before trying $HOME or
$startup-path. |
||||||||||||||||||||||||||||||||||||||||||||||||||||
| $look-in-home | true if startup files are sought in the home directory
before trying $startup-path. |
||||||||||||||||||||||||||||||||||||||||||||||||||||
| $majormode | current majormode, if any (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $majormode-hook | procedure to override suffix/preamble rules | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $match | last matched magic pattern (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $menu-file | the name of the menu file (e.g. .vilemenu) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $mode | current mode ("command","insert","overwrite") (rd. o.) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $modeline-format | format of mode lines. see "Mode line customization". | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $modeline-limit | maximum inline offset to scan for mode lines | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $modified | is current buffer modified or not? (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $ncolors | number of displayed colors, must be power of two | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $ntildes | percent of window filled by ~ chars, at end of buffer | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $ocwd | previous directory (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $os | "dos", "vms", "os/2", "win32", and "unix", although the latter may be replaced with a more specific name derived from vile's configure script. (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $pagelen | number of screen lines in use by editor | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $pagewid | current screen width | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $palette | current palette string | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $patchlevel | current patch-level (empty for release) (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $pathlist-separator | separator for lists of pathnames, e.g., $PATH | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $pathname | current "path-like" word, under the cursor. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $pathname-separator | separator for levels of pathnames, e.g., '/' | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $pending | typeahead pending flag (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $pid | returns vile's process-id (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $position-format | format of ^G command. see "Mode line customization". | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $progname | returns "vile" or "xvile" or "winvile". (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $prompt | the command-line prompt string ": " | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $qidentifier | current qualified name (as with C++ ::) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $read-hook | name of procedure to run after a file is read | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $replace | replacement pattern | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $return | set within a macro to provide $_ on completion | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $search | search pattern | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $seed | current random number seed | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $shell | name of the shell program for spawned commands. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $sres | current screen resolution | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $startup-file | the name of the startup file (e.g. .vilerc). Normally
this is only a filename, but can be an absolute path
to override $startup-path. |
||||||||||||||||||||||||||||||||||||||||||||||||||||
| $startup-path | where to find the startup file, i.e., a colon-separated list of directories on Unix-like systems. On Windows, use semicolon for separating the items in the list. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $status | returns the status of the last command | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $system-crlf | the default value for dos mode, which can be preset using
-u or -U options |
||||||||||||||||||||||||||||||||||||||||||||||||||||
| $system-name | returns the operating system name shown in the
version command |
||||||||||||||||||||||||||||||||||||||||||||||||||||
| $term-cols | number of columns in terminal window (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $term-encoding | terminal's encoding support (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $term-lines | number of lines in terminal window (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $term-resizes | true if vile handles terminal-resizing (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $title | current window title (X11, win32 versions only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $title-encoding | encoding of xterm window title, e.g., "8bit" for ISO-8859-1 or "utf-8". | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $title-format | format of window title. see "Mode line customization". | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $version | current version number (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $with-prefix | string set by "~with" directives (read only) | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $wlines | number of lines in current window | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $word | current "word", a sequence of nonblanks | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $write-hook | name of procedure to run before a file is written | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $xdisplay | the value to set $DISPLAY when running $xshell. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $xshell | name of the terminal program for spawned xvile commands. | ||||||||||||||||||||||||||||||||||||||||||||||||||||
| $xshell-flags | command-line flags after $xshell, normally "-e" |
In addition to the state variables, you may set and use the values of the editor modes (i.e., universal modes, buffer-only modes or window-only modes), e.g., "setv $dos=true". The global values of the editor modes are not visible to the expression evaluator.
User-defined variables can also be set and used; their names are prefixed with the '%' character.
Response variables (a '@' followed by a prompt-string) cause vile to prompt for input with the given prompt-string.
Buffer variables (a '<' followed by a buffer name) return the current line of the specified buffer, automatically setting the position to the next line.
There are also functions available, which can act on those variables, or on hard-coded values. Operations are expressed in prefix notation, so to add to numbers you would say "&add 3 5". You may use any unique abbreviation of the function names.
The "describe-user-functions" command shows this information:
| Name | Args | Description |
|---|---|---|
| &abs | 1 | absolute value of a number |
| &add | 2 | add two numbers together |
| &and | 2 | logical and |
| &ascii | 1 | char to integer conversion |
| &bchanged | 1 | true if given buffer is modified |
| &bind | 1 | lookup what function name is bound to key |
| &cat | 2 | concatenate string |
| &cclass | 1 | character class (see "show-printable") |
| &chr | 1 | integer to char conversion |
| &classof | 1 | inverse of &isa, returns classes for param |
| &cmatch | 2 | caseless match regular-expression value |
| &date | 2 | format 2nd param with 1st, like strftime. |
| &default | 1 | initial/default value for mode or state variable |
| ÷ | 2 | division |
| &dquery | 2 | prompt user for input, given default value |
| &env | 1 | retrieve a system environment variable |
| &equal | 2 | numeric equality |
| &error | 1 | true if the parameter was ERROR |
| &execable | 1 | true if file is exec'able |
| &fchanged | 1 | true if file for given buffer is modified |
| &filter | 1 | true if the given majormode's filter is builtin |
| &ftime | 1 | modification-time of the given file, as a number |
| &geq | 2 | numeric greater than or equal |
| &get-key | 0 | (alias for >key) |
| &get-key | 0 | (alias for >key) |
| &get-completion | 2 | get name-completion for given category and value (see below for arguments) |
| &get-motion | 1 | (alias for >motion) |
| &get-sequence | 0 | (alias for >sequence) |
| &global | 1 | retrieves global mode setting |
| &greater | 2 | numeric greater than |
| > | 2 | numeric greater than |
| >key | 0 | get 1 character |
| >motion | 1 | get keycode motion sequence for the binding |
| >sequence | 0 | get keycode sequence, e.g., #1 |
| &indirect | 1 | evaluate indirect value |
| &isa | 2 | check if the second param is a member of first |
| &left | 2 | left string(string, len) |
| &length | 1 | string length |
| &leq | 2 | numeric less than or equal |
| &lessthan | 2 | numeric less than |
| &local | 1 | retrieves local mode setting |
| &lookup | 2 | look for filename (see below for arguments) |
| &lower | 1 | lower case string |
| < | 2 | numeric less than |
| &match | 2 | match regular-expression value |
| &mclass | 1 | returns the mode's class, e.g., buffer or Major |
| &middle | 3 | mid string(string, pos, len) |
| &modulo | 2 | modulus |
| &negate | 1 | negate |
| &neq | 2 | numeric inequality |
| ¬ | 1 | logical not |
| &or | 2 | logical or |
| &path | 2 | extract/translate pathname (see below for args) |
| &pcat | 2 | concatenate directory and filename |
| &pquote | 1 | quote pathname if needed, e.g., embedded spaces |
| &qpasswd | 1 | prompt user for password string |
| &query | 1 | prompt user for input |
| &random | 1 | get a random number from 1 to n |
| &rd | 1 | is a file readable |
| &readable | 1 | is a file readable |
| ®ex-escape | 1 | returns value with regex metacharacters escaped |
| ®ister | 1 | value of register (1-character name) |
| &right | 2 | right string(string, pos) |
| &rnd | 1 | get a random number from 1 to n |
| &sequal | 2 | string logical equality check |
| &sgeq | 2 | string greater than or equal |
| &sgreater | 2 | string logical greater than |
| &sgt | 2 | string greater than |
| &sindex | 2 | find the index of second string in first |
| &sleq | 2 | string less than or equal |
| &sless | 2 | string logical less than |
| &slt | 2 | string less than |
| &sneq | 2 | string inequality |
| &stime | 1 | system-time, as a number |
| &stoken | 3 | true if token found in string, given delims |
| &subtract | 2 | subtraction |
| × | 2 | multiplication |
| &token | 3 | select n'th token of string, given delims |
| &translate | 3 | translate "from" to "to" for given string. |
| &trim | 1 | trim whitespace from string |
| &upper | 1 | uppercase string |
| &word | 2 | select n'th word of string, blank-separated |
| &writable | 1 | is a file writable |
The &get-completion function takes two arguments. The first is a category (one of "buffer", "command", "directory", "filename", "register" or "tags"). The second is an initial value to complete.
The &lookup function takes two arguments. The first is a keyword and the second is a filename. Keywords may be combined with '+', e.g., r+bin to find a readable file in the directory where vile's executable is. The keywords are for location:
| bin | look in vile's directory |
| current | look in the current directory |
| home | look in user's $HOME directory |
| insecure | permit matches on files with insecure permissions (see check-access). |
| libdir | look along $libdir-path |
| path | look along user's $PATH |
| startup | look along $startup-path |
and for access type, defaulting to an existence check:
| execable | test if file is exec'able |
| readable | test if file is readable |
| writable | test if file is writable |
Search order is fixed: current, home, bin, startup, path, libdir
The &path function takes two arguments. The first is a keyword and the second is a pathname. Keywords are: end (suffix of the filename), full (absolute path), head (directory), root (filename without suffix), short (relative path), tail (filename).
Primitive flow-of-control within a macro may be obtained with certain directives. Macro directives start with a "~" and include the following: (see the file macros.doc for more detail)
| Name | Description | |
|---|---|---|
~break
|
exit a ~while loop |
|
~else
|
default conditional execution | |
~elseif cond |
alternate conditional execution | |
~elsewith tokens |
alterate tokens to following commands | |
~endif
|
finish conditional execution | |
~endm
|
finish a macro | |
~endwhile
|
finish a ~while loop |
|
~endwith
|
finish a ~with block |
|
~force
|
force macro to continue even if command fails | |
~goto label |
jump to a label in the current macro | |
~hidden
|
do not update screen while the macro executes | |
~if cond |
start conditional execution | |
~local vars |
save specified variables, restore when macro terminates | |
~quiet
|
suppress messages while the macro executes | |
~return
|
terminate current macro | |
~trace cond |
set $debug trace | |
~while cond |
execute a loop if the condition is true | |
~with tokens |
prepend tokens to following commands |
Line labels begin with a "*" as the first nonblank char, like:
*LBL01
You would jump to this with:
~goto LBL01
Lines ending with '\' are joined before interpreting them.
There are a few places within vile where a user-specifiable procedure will be executed if desired. These points are referred to as "hooks". Hooks are specified by special variables which hold the name of a procedure to run at that point in the code. For instance, there is a "cd-hook", which is run when you changej directories. Assume the following are included within a vile startup file:
store-procedure my-cd-action
write-message &cat &cat &cat "moved from " $ocwd " to " $cwd
~if &seq $progname "xvile"
set-variable $title $cwd
~endif
~endm
set cd-hook my-cd-action
Whenever the current directory is changed within the editor (via the "cd" command), my-cd-action will print a message and, under xvile, change the window title.
The following hooks are currently implemented:
| $autocolor-hook | applies syntax coloring to modified buffers when the keyboard is idle for a user-configurable time period |
| $buffer-hook | run when switching to a buffer |
| $cd-hook | run when changing directories |
| $exit-hook | run when quitting |
| $majormode-hook | procedure to override suffix/preamble rules |
| $read-hook | run after a file is read |
| $write-hook | run before a file is written |
Be careful with "buffer-hook". Executing commands in the hook which themselves switch buffers is not recommended. In general, all the hooks are a little dangerous, since vile has not been written with re-entrancy foremost in mind. One should avoid putting actions in hooks which might cause the hook to be re-executed. (vile keeps the hook procedure itself from being re-executed, to prevent recursion, but the code surrounding the call to it may not be safe either.)
To prevent vile from thinking that a failed command is an error in the macro, you can put "~force" in front of it. So, to write a macro which will run the "man" command on the identifier under the cursor, where you don't really consider it an error if the command fails, you might use:
9 store-macro
~force 1 shell-command &cat "man " $identifier
~endm
bind-key execute-macro-9 ^X-m
(The argument '1' suppresses the "press return" prompt which normally appears after a command runs, since man runs a pager which does this anyway.)
The "screen-search-forward" command could be re-implemented as:
10 store-macro
~force search-forward $identifier
~endm
bind-key execute-macro-10 ^X-/
And the "screen-search-pattern-grab" command, normally bound to ^A-/, could be implemented with:
11 store-macro
set-variable $search $identifier
write-message &cat "Search pattern is now " $search
~endm
bind-key execute-macro-11 ^A-/
A variation, which will not find the identifier if it is a substring of another word, is:
12 store-macro
~force search-forward &cat "\\<" &cat $identifier "\\>"
~endm
This works by surrounding the string with the \< and \> regular expression metacharacters.
Here's another example, which finds C++ qualified identifiers, and uses them for a tag lookup:
; Implement ^A-^] for qualified-name tag lookup
24 store-macro
backward-character
~local $search
search-forward "^[a-zA-Z_][a-zA-Z0-9_:]*"
write-message &cat "Tag pattern is now " $match
~force find-tag $match
~endm
bind-key execute-macro-24 ^A-^]
(The "backward-character" is needed because "search-forward" will always skip the cursor position when scanning, so as to always find the next occurrence. The directive ~local is used to avoid disturbing the search string.)
Note that for simple key-remappings, binding is often preferable to creating a macro. Some people prefer using lower-case 'g' to as an equivalent to 'G', to goto a specific line. If done as a macro, like this:
3 store-macro
goto-line
~endm
bind-key execute-macro-3 g
then both g and G go to the end of the file, but whereas 1000G goes to line 1000, 1000g goes to the end of the file 1000 times. It is easier (and more correct) to do:
bind-key goto-line g
A couple more examples of slightly more complex macros: They cause a jump to the next (or previous) line of the same (or lesser) indent, skipping over empty lines. (Thanks to MIURA Masahiro)
; macro 1 - back to the line of same indent
;
1 store-macro
first-nonwhite
set-variable %indlev $curcol
~force back-line-at-bol
~if &seq &trim $line ""
~goto L1
~endif
~while &les %indlev $curcol
*L1
~force back-line-at-bol
~if &seq $status "FALSE"
~return
~endif
~if &seq &trim $line ""
~goto L1
~endif
~endwhile
~endm
bind-key execute-macro-1 ^X-[
; macro 2 - forward to the line of same indent
;
2 store-macro
first-nonwhite
set-variable %indlev $curcol
~force down-line-at-bol
~if &seq &trim $line ""
~goto L2
~endif
~while &les %indlev $curcol
*L2
~force down-line-at-bol
~if &seq $status "FALSE"
~return
~endif
~if &seq &trim $line ""
~goto L2
~endif
~endwhile
~endm
bind-key execute-macro-2 ^X-]
; Use "@d" to change cwd to the dir containing the current file
; (contributed by Richard Hussong). Keep in mind that "^M" is an
; explicit CR and that ":cd -" reverts cwd to its previous value.
store-procedure cdcur
cd &path head $cfilname
~endm
use-register d load-register ":cdcur^M"
;; Underline current line with user-specified char. Ex:
;; blah blah blah blah <-- curr line
;; +++++++++++++++++++ <-- underline with +
;; from Daniel L. Ashbrook .
store-procedure underline-currline
write-message "enter underline char now..."
set-variable %linechar >key
write-message ""
; don't underline trailing whitespace (trivial)
trim-lines-til end-of-line
; don't underline leading whitespace (nontrivial)
goto-bol
setv %ldspace=&equ $char &ascii ' '
setv %ldtab=&equ $char &ascii "\t"
setv %ldwhite=&or %ldspace %ldtab
~if %ldwhite
~force substitute-til next-punctuated-word '^\b\b*' ''
~endif
; compute length sans lead/trail whitespace
set-variable %linelength $llength
~if %ldwhite
; put leading whitespace back
undo-change
; it's not possible to disable the screen clutter of
; visual-matches mode (following a substitution)
; for all buffers from within a macro. so substitute
; for an improbable char (which achieves desired effect)
~force substitute-til next-punctuated-word &chr \xff &chr \xff
~force clear-visual-matches
~endif
unset-variable %ustring
set-variable %i 0
; build underline string in memory and insert with a
; single operation (optimizes undo)
~while &less %i %linelength
set-variable %ustring &cat %ustring %linechar
set-variable %i &add %i 1
~endwhile
; force ustring to align with prev line
~local $autoindent
setv $autoindent=true
goto-eol
append-string &chr 13 ; 13 -> CR
insert-string %ustring
~force next-line
goto-bol
~endm
bind-key underline-currline #-
; macro 14 - grep for the word under the cursor, and put the result
; in a buffer named after that word. set the error-buffer,
; so that ^X-^X may be used to visit the lines found by grep.
; (we have to set error-buffer explicitly, since we renamed
; the buffer -- otherwise it tracks the last pipe read by vile)
14 store-macro
set-variable %grepfor $identifier
edit-file &cat "!egrep -n " &cat %grepfor " *.[chs]"
rename-buffer %grepfor
error-buffer %grepfor
~endm
bind-key execute-macro-14 ^A-g
As a hint, it is (almost?) never correct to write a ':' command when creating a programmed macro. For instance, if you find yourself writing something like:
&cat ":!chmod +w " $cfilname
&cat ":e! " $cfilname
(in an attempt to make a buffer writable before editing it), then what you really want is:
shell-command &cat "chmod +w " $cfilname
replace-with-file $cfilname
Furthermore, some things are just as easy if done with a "keystroke" macro rather than a programmed macro:
; use this as '@w'
use-register w load-register ":!chmod +w %^M:setl noview^M:w^M"
or
map ^A-w ":!chmod +w %^M:setl noview^M:w^M"
(Of course you need to replace the ^M's with real carriage-returns.)
Another example of a fairly complex vile procedure can be found in the file "pictmode.rc". The code there implements a primitive means of drawing "ASCII art". To use it, first ":source pictmode.rc" and then "run pic". See the comments at the top of pictmode.rc for more information...
Searches use regular expressions, which, as in vi, may be magic by default or not.
vile introduces some new magic metacharacters.
The code that implements the expressions is based directly on Henry Spencer's regexp code. Quoting from the original man page:
[For ease of reference, the metacharacters are noted on the left margin.]
\|
|
A regular expression is zero or more branches, separated by `\|'. It matches anything that matches one of the branches. |
| A branch is zero or more pieces, concatenated. It matches a match for the first, followed by a match for the second, etc. | |
*
|
A piece is an atom possibly followed by `*', `\+', or `\?'. An atom followed by `*' matches a sequence of 0 or more matches of the atom. An atom followed by `\+' matches a sequence of 1 or more matches of the atom. An atom followed by `\?' matches a match of the atom, or the null string. [i.e., `\?' matches 0 or 1 occurrences] |
\( \)
|
An atom is a regular expression in backslashed parentheses (matching a match for the regular expression), a range (see below), (matching any single character), `^' (matching the null string at the beginning of the input string), `$' (matching the null string at the end of the input string), a `\' followed by a single character (matching that character), or a single character with no other significance (matching that character). |
\< \>
|
In addition, vile atoms may be: \< and \>, which match the beginning and end of a "word". |
| Vile recognizes the X/Open regular expression character classes (and additional character classes), as well as shorthand expressions for them. You can use the shorthand expressions in a range or as an atom. Each shorthand expression has a complement, e.g., \w and \W. | |
\i \I
|
[:alnum:] [:alpha:] [:blank:] [:cntrl:] [:digit:] [:file:] [:graph:] [:ident:], alphanumeric (plus '_') [:lower:] [:octal:] [:print:], printable (note that space is printable) [:punct:] [:space:] [:upper:] [:xdigit:] |
[ ]
|
A range is a sequence of characters enclosed in `[]'. It normally matches any single character from the sequence. If the sequence begins with `^', it matches any single character not from the rest of the sequence. If two characters in the sequence are separated by `-', this is shorthand for the full list of ASCII characters between them (e.g. `[0-9]' matches any decimal digit). To include a literal `]' in the sequence, make it the first character (following a possible `^'). To include a literal `-', make it the first or last character. |
| Additionally for vile, if "ignorecase" is set, then all literal matches, including those in character classes, are done without regard to upper and lower case. | |
| In magic mode, the following set of metacharacters must be preceded by '\' to hide their special meaning: * [ . ^ $ These characters are special if they are preceded with a '\': ? + ( ) | < > | |
| If magic mode is not on, only ^ and $ are special if not escaped. All of the following must be preceded with a '\' to be special, otherwise they are taken literally: ? + ( ) | * [ . < > | |
\1 \9
|
Replacement subexpressions are supported when substituting. That is, if part of an expression is contained in \( and \), then the part of the matched text in between those symbols will be substituted for an occurrence of \1 in the replacement pattern. Up to 9 such substitutions can be made. The special symbol & will & substitute for the entire match string. |
~
|
The tilde (~) character will expand immediately when it is typed to be the contents of the previously entered replacement pattern. [ Earlier versions of vile made this version of the pattern available immediately, as a default response, but this made it difficult to substitute nothing after previously substituting something. ] |
\U \L
|
The replacement part of the substitution may also contain the special sequences \U and \L, which cause the replacement to be forced to uppercase or lowercase until a terminating \E is found; \u and \l, which force the case of a single character; and \b, \f, \r, \t, \n, which insert the usual ASCII character. Note that vile mimics perl's handling of \u\L\1\E instead of vi's. Given :s/\(abc\)/\u\L\1\E/ vi will replace with "abc" whereas vile and perl will replace with "Abc". This is somewhat more useful for capitalizing words. |
On startup, in the absence of '@' arguments, vile attempts to read the file ".vilerc" ("vile.rc" on non-Unix hosts) in the current directory, then in $HOME, and then in several host-specific locations (see the "Invocation" topic below for complete details). If found, vile executes the startup file's commands. It is possible to nest such executions. For example, you might keep your general default settings in your home directory, and put the following lines in a .vilerc in a directory in which you prefer tabs be set to 4 spaces:
source "$HOME/.vilerc"
set tabstop 4
The quotes surrounding the filename are necessary to protect the name from interpretation as a vile variable, since it starts with the '$' character.
Files can be executed at any time with the ":source" (or ":execute-file") command. There are control structures available, such as ~while, ~if, etc. Refer to the file doc/macros.doc which is distributed with vile for more information.
Nesting of source'd files is limited to a depth of ten, to prevent infinite recursion.
The ';' character can be used as a comment character in command files, but not necessarily on the same line as valid commands. Put your comments on separate lines to be safe.
vile searches for a startup or command file in these locations (and in the order listed):
1 - current working directory
2 - directory specified by $HOME
3 - if host is not Unix
vile executable directory
fi
4 - each directory specified in $VILE_STARTUP_PATH. If
this environment variable is not set, the following
host-specific defaults are internally assumed:
VMS: sys$login,sys$sysdevice:[vmstools],sys$library
DOS, OS/2 and Win32: /sys/public;/usr/bin;/bin;/
Unix: depends on whether or not $VILE_STARTUP_PATH was
set when vile was configured prior to
compilation. If set, then the value of that
environment var is compiled into the editor,
else the default configure "datadir" is
selected, which is either:
/usr/local/share/vile (typical root build)
${prefix}/share/vile (nonroot build)
5 - if host is not Unix, each directory specified in:
$PATH
$VILE_LIBDIR_PATH
fi
If the variable VILEINIT is set in the environment, it is used as a set of vile commands to initialize the editor. As a not-very-useful example of a VILEINIT sequence, the following setting recreates portions of the default initialization behavior:
export VILEINIT
VILEINIT="
~if &rd \"./.vilerc\"
source \"./.vilerc\"
~else
~if &rd \"$HOME/.vilerc\"
source \"$HOME/.vilerc\"
~endif
~endif"
Other environment variables:
The default value,
/\\.\\(UTF\\|utf\\)[-]\\?8$//, simply strips the
most common suffixes used for wide-character locales. For
example, "en_US.UTF-8" would be converted to "en_US". If your
computer's locale tables do not support that, you can modify
the pattern to help vile find the narrow locale value that
works.
Note: For simplification, the filters.rc script assumes that the filter programs are in $PATH. The $libdir-path feature may not work for you out-of-the-box, since your shell's initialization file (e.g., ".cshrc") may set $PATH. One solution (other than adding /usr/local/lib/vile to $PATH) is to set the vile variable $shell to /bin/sh, assuming you have no Bourne shell ".profile" to set $PATH. Then vile's modification of $PATH affects the filter process and also runs faster.
The command line options are fairly straightforward. vile supports running just any command after a '+', as does vi. It also has some shortcut options to support the commonly used '+400' to go to line 400 and '+/foo' to search for foo. Command files can be explicitly executed on startup by prefixing them with the '@' character, as in "vile @mycmds file.c". This will suppress the operation of VILEINIT and the .vilerc files.
vile implements an interface to the UNIX crypt function, like standard vi, and can apply this to your buffers either automatically (via a mode setting) or manually (via an explicit command). The algorithm is reversible, so encrypting a previously encrypted buffer will undo that encryption.
The encryption key for a buffer will be a) inherited from the global cryptkey which was set via the vile command line (-k) if it exists, b) set with the set-crypt-key (^X-X) command, or c) obtained from the user interactively. The details of this are a little messy, and should probably be cleaned up somewhat. The buffer's key will remain active until changed or reset.
If "crypt" mode is on, then when the buffer is written the user will be prompted for the encryption key to use if none has yet been set. If "crypt" mode is on, and an encryption key has been set, then the buffer will be encrypted when read. In practice this means you need to read the file, then set crypt mode, then reread the file. (Or, equivalently, create the buffer, set crypt mode, and then insert the file into it (with ":r").
As an alternative to UNIX crypt, the collection of macros in the file macros/gnugpg.rc facilitates use of GNU's gpg encryption package. gpg and gnugpg.rc work well on both Unix and win32 hosts.
The "vi -r" option, used to recover an edited buffer after a system crash, is not present in vile. If vile itself crashes (usually (though infrequently :-) due to a bug, but perhaps due to an externally applied signal), it attempts to save any modified buffers in a temporary directory and, on a Unix host, sends mail to the user to that affect. The selection of the temporary directory is host-specific, as follows:
$TMPDIR/vileDXXXXXX
/var/tmp/vileDXXXXX
/usr/tmp/vileDXXXXX
/tmp/vileDXXXXXX
./vileDXXXXXX
Saved buffers are written to disk using the path ./V<buffername> .
$TMPDIR/vileDXXXXXX
./vileDXXXXXX
where "XXXXXX" is a unique suffix created by mktemp().
If system crashes are frequent on your system, you should stop using it. You might also consider the "autosave" and "autowrite" options, which will cause more frequent saves of your work.
At the bottom of each window is a mode (or "status") line which is used for displaying certain characteristics of the window and the buffer associated with it. On most displays, this mode line will be highlighted in reverse video or via other means in order to visually separate windows and to distinguish the mode line from text displayed in the window.
The editor variable "modeline-format" is set to a string which controls formatting of mode lines. This variable is user settable and thus may be used to customize the display of mode lines. The format specifiers which may appear in the format control strings are as follows:
| Format | Description |
|---|---|
| %b | buffer name |
| %c | column number if "ruler" is set |
| %C | character value at current edit-position. |
| %f | file name when not internal buffer and when not the same as the buffer name. |
| %F | file name when it is internal buffer name and not the same as the buffer name. |
| %i | insert/overwrite/replace mode indicator, displayed only when in insert, overwrite, or replace mode. When not in one of these modes, the separator character (often "-", "=", or " ") will be displayed. |
| %l | line number to be displayed if "ruler" is set |
| %L | number of lines in buffer, if ruler is set |
| %m | major mode(s), e.g., cmode, view-only, etc. Displayed in square brackets. |
| %M | brief version of "%m", omitting "mode", etc. |
| %n | file leaf name when not internal buffer name, otherwise the buffer name. |
| %N | absolute file path when not internal buffer name, otherwise the buffer name. |
| %p | line number as percentage of number of lines if "ruler" is set |
| %P | line number as percentage of number of lines |
| %r | relative file name when not internal buffer name, otherwise the buffer name. |
| %S | rough position of window with respect to buffer (top, bot, all, emp, mid) when ruler not set (or ruler is set, but buffer is empty). |
| %= | middle separator; should appear at most once in a format string. This indicates where to separate the left and right hand portions of the mode line with a long string of dashes (or whatever the separator character is). |
| %- | single occurrence of separator character |
| %| | eighty column indicator |
| %% | percent sign |
| %: | colon |
| %{name} | any internal mode/variable value, given its name |
Some of the format specifiers (%f, %F, %m, %l, %c, %p, %S, %L, %C) are conditionally displayed. For example "%m" will display the major modes only if there are some major modes set or if the buffer has been modified (which is sort of a major mode). Similarly, "%F" and "%f" will cause the associated file name to be displayed when the buffer is of the appropriate type (a scratch buffer or not) and the shortened file name is different from the buffer name. It is desirable at times to cause a prefix string and/or a suffix string to be emitted along with the string obtained after conversion of the format specifier. This may be done by following the format specifier with a colon, the prefix string, another colon, the suffix string, and another colon. For example, "%l:(:,:%c::) :" might be used to display the line and column number for "ruler" mode. Note that either or both of the prefix and suffix strings may be empty.
Characters in the string which are not part of a format specifier are output verbatim.
The default format control string is as follows:
"%-%i%- %b %m:: :%f:is : :%=%F: : :%l:(:,:%c::) :%p::% :%C:char ::%S%-%-%|"
Mode lines for some versions of vile previous to version 4.7 can be obtained with the following format string. This will remove the percentage indication from the mode line when in ruler mode and also shift the ruler indicator to the far right in the mode line.
"%-%i%- %b %m:: :%f:is : :%=%F: : %-%-%-%-:%l:(:,:%c::):%S::%-%-:%|"
The editor's support of color varies from host to host. On some hosts, such as VMS and DOS, limited capability exists. On other hosts, full-blown syntax coloring is provided for a wide variety of languages and tools. Prior to discussing the ins and outs of syntax coloring, it helps to first describe several key color features and concepts.
Depending on the host, vile comes in two flavors:
In general, GUI vile supports a richer set of color features and capabilities than console vile.
Depending on the capabilities of the host operating system and the underlying display hardware, vile supports a palette of up to 16 colors. The editor's color names are fixed, as shown in this list:
| External user name | Internal vile name |
|---|---|
| black | C0 |
| red | C1 |
| green | C2 |
| brown | C3 |
| blue | C4 |
| magenta | C5 |
| cyan | C6 |
| lightgray | C7 |
| gray | C8 |
| brightred | C9 |
| brightgreen | CA |
| yellow | CB |
| brightblue | CC |
| brightmagenta | CD |
| brightcyan | CE |
| white | CF |
Note that both xvile and winvile provide support for the mapping of arbitrary RBG values to the above color names, thus permitting the creation of a customized color palette.
When a color X server and color display are available, xvile's default colors are modified by changing the editor's color resources (refer to the topic "X Resources" in this help file). So, for example, the following line in an .Xdefaults or .Xresources file maps "gray" above to red:
XVile.color.fcolor8: rgb:ff/0/0
or
XVile.color.fcolor8: red
winvile's default colors are changed via the editor's set-rgb-palette command. Mirroring the example above, map "gray" to red like so:
set-rgb-palette gray 255 0 0
vile supports bold, italic, underline, and reverse display attributes. These attributes may be used to modify/enhance any of the existing colors (e.g., bold blue), or render text as a "color" in its own right (e.g., configure the editor to highlight all matched search strings in the reverse attribute).
The show-colors command (i.e., ":show-colors") displays the editor's current color and attribute mappings.
Note that on some unix hosts it's possible to run standard vile in a color xterm and thereby gain access to an expanded color palette (albeit often limited to 8 colors). However, this is only possible when:
Hint 1: Modern xterm and similar terminal emulators support 8 colors (i.e., ensure that the correct $TERM is used, e.g., "export TERM=xterm" or csh equiv is included in your shell startup file).
Hint 2: To determine if the editor was compiled with terminfo, type :show-variables and examine the value of $cfgopts. If this variable includes the string "terminfo", you've got a shot. If "termcap" is listed instead, vile's color palette is limited to black and white (i.e., no color). Assuming your host supports terminfo, the following build commands force the editor to use that library:
$ make clean; ./configure --with-ncurses; make
For additional hints and help, try this URL:
All hosts support visual-matches mode, which highlights search text with either a simple color (no modifiers) or a display attribute. To see the list of supported colors and attributes, type:
:set visual-matches=<tab><tab>
To learn more about this mode, search for "visual-matches" elsewhere in this help file.
On hosts and display hardware that support it, the editor's foreground color may be set to a simple color value (no attribute modifiers allowed). Type:
:set fcolor=<tab><tab>
for a list of supported colors.
On hosts and display hardware that support it, bcolor mode sets the editor's background color. Bcolor utilizes the same color list as fcolor.
A buffer may be manually or programmatically encoded with strings that cause the editor to render text in arbitrary color/attribute sequences. For example, consider the following data:
^A3C1:red text, ^A4B:bold text
Given a suitable command, vile will render this as:
<begin red>red<end red> text, <begin bold>bold<end bold> text
It's possible to mix colors and attribute as well:
^A8BC1:bold red text
which is rendered as:
^A8BC1:<begin bold&red>bold red<end bold&red> text
These sequences are the building blocks of syntax coloring. For a more detailed discussion of attribute control sequences, refer to the topic "Writing your own filters" in this help file.
vile colors a buffer via these steps:
| Color Feature | VMS (std) | VMS (GUI) | DOS | OS/2 | Win32 (std) | Win32 (GUI) | Unix (std) | Unix (GUI) |
|---|---|---|---|---|---|---|---|---|
| Visual Matching | Y | Y | Y | Y | Y | Y | Y | Y |
| Foreground Color | N | Y | Y | Y | Y | Y | [2] | Y |
| Background Color | N | Y | Y | Y | Y | Y | [2] | Y |
| Attr. Sequences | Y | Y | Y | Y | Y | Y | [3] | Y |
| Syntax Coloring | N | N | N | [1] | Y | Y | [3] | Y |
Note 1: vile's filter mechanism blocks (hangs) when processing "large" buffers. Consequently, syntax coloring is not recommended, except if one could use the builtin-filters configuration.
Note 2: Requires a terminfo terminal type that supports color.
Note 3: If a terminal type supporting color is unavailable, then "coloring" is limited to the use of attributes like bold, underline, etc.
vile's source distribution includes an extensive set of filters that color many languages and text file formats, including (but not limited to):
C/C++, Java, Perl, HTML, shell scripts
Filters come in two flavors: builtin and external. Builtin filters are bound directly into the editor and invoked via function calls. External filters are standalone executables invoked via a pipe and typically named "vile-xxx-filt", where "xxx" denotes the target text/language. Note that "xxx" is usually the same name assigned to vile's corresponding builtin filter and "majormode" (there are some exceptions). The following table lists example paired filter and majormode names:
| Language Name | Builtin Filter Name | External Filter Name [1] | Majormode Name[2] |
|---|---|---|---|
| C | c | vile-c-filt | cmode |
| HTML | html | vile-html-filt | htmlmode |
| Perl | pl | vile-pl-filt | perlmode |
| sh | sh | vile-sh-filt | shmode |
For a complete listing of all filters and supported languages and text file formats, refer to the file doc/config.doc in the editor's source distribution.
[1] Whether the editor uses builtin or external filters depends solely upon configuration options specified when the editor is compiled and linked (see doc/config.doc for details). As you might expect, builtin filters offer faster syntax coloring at the cost of a larger editor executable. For the purposes of this document, it's assumed that the editor is bound with builtin filters.
[2] Majormodes are an interesting subject in their own right, but won't be discussed much within the context of syntax coloring. For more info, refer to the help topic "Majormodes" in this help file, as well as the file doc/modes.doc.
[3] Previous releases of vile utilized a syntax filtering system that actually applied color attributes to a target buffer, thereby damaging the editor's undo history. vile version 8.3 (and later) utilizes a new command, called "attribute-from-filter-til", which applies coloring information directly from the filter's output stream without modifying the affected buffer.
The remainder of this section of the help file includes a step-by-step description of syntax coloring configuration, as well as pointers to related features.
There are three configuration recipes, each dependent on the target host and/or the user's privilege level.
The simplest install copies the editor to a directory in the system PATH (we'll assume /usr/local/bin), and copies all syntax coloring data and macro files to /usr/local/share/vile. The following commands accomplish that task:
unset VILE_STARTUP_PATH VILE_LIBDIR_PATH
make clean; ./configure --with-builtin-filters; make
make install
Users should take these additional steps:
1) add the following to their $HOME/.vilerc startup files:
source "filters.rc"
2) execute these shell commands (as necessary):
mkdir $HOME/.vile
cp /usr/local/share/vile/vile.keywords $HOME/.vile
That's it. Now skim through the "Manual recipe" topic below and then pay attention again when you hit the topic entitled "Testing the configuration". With regard to the remainder of this discussion, the term "COLORDIR" refers collectively to the list of directories where vile searches for keyword files. This is the list:
vile subdirectory of the home
directoryWhen searching directories which it does not
“own;â€, vile looks for the
filename with a leading “.;â€. The
which-keywords macro illustrates this best,
e.g.,
which-keywords cmode
produces this output in the [Which Keywords]
buffer:
Show which keyword-files are tested for:
cmode
(* marks found-files)
$cwd
./.c.keywords
$HOME
~/.c.keywords
~/.vile/c.keywords
$startup-path
* /usr/share/vile/c.keywords
The simplest install copies the editor and all data and macros file to a writable directory tree (we'll assume $HOME/local). This syntax does the job:
unset VILE_STARTUP_PATH VILE_LIBDIR_PATH
make clean
./configure --prefix=$HOME/local --with-builtin-filters
make
make install
These additional steps are required:
1) add the following to the $HOME/.vilerc startup file:
source "filters.rc"
2) execute these shell commands (as necessary):
mkdir $HOME/.vile
cp $HOME/local/share/vile/vile.keywords $HOME/.vile
3) add $HOME/local/bin to $PATH (if not already specified)
That's it. Now skim through the "Manual recipe" topic below and then pay attention again when you hit the topic entitled "Testing the configuration". With regard to the remainder of this discussion, the term "COLORDIR" refers collectively to the directories $HOME/.vile or $HOME/local/share/vile as appropriate.
You may choose to not use the winvile install/setup program, or else you may be installing console Win32 vile. In either case, you can always manually configure vile for Win32. For the purposes of this discussion, it is assumed that the editor is not built from sources, but instead obtained from precompiled binaries, as described next.
1) create a directory (hereafter referred to as COLORDIR) to store the editor's external color keyword and macro files. Example COLORDIR name: c:\util\vcolor
2) obtain these two distributions:
https://invisible-island.net/archives/vile/filters.zip
https://invisible-island.net/archives/vile/vile-w32.zip
3) extract the contents of filters.zip into COLORDIR.
4) extract the contents of vile-w32.zip into a temp directory. From within this temp directory:
a) copy *.rc to COLORDIR. Note that the most important of these files is filters.rc .
b) copy vile.exe, vile.hlp, and winvile.exe to a directory in your PATH. Note that vile.exe and winvile.exe are both bound with all of the editor's builtin filters.
5) edit your startup file (vile.rc) and add this line:
source "filters.rc"
6) export these environment variable settings:
VILE_STARTUP_PATH=COLORDIR VILE_LIBDIR_PATH=COLORDIR
Example entries in Win9x/ME's autoexec.bat:
SET VILE_LIBDIR_PATH=c:\util\vcolor
SET VILE_STARTUP_PATH=c:\util\vcolor
On a Win/NT/2K host, env vars are initialized via a control panel applet. WinXP uses a different mechanism.
Basic configuration is now complete. Filters.rc installs several stored procedures, including:
| Macro Name | Binding | Function |
|---|---|---|
| HighlightFilterMsg | ^X-q | Colors the current buffer if a majormode and filter exist for same. |
| HighlightClear | ^X-Q | Clears the current buffer's color attributes. |
| set-highlighting | <none> | Attach a major mode to a buffer and re-color same. More about this below. |
For a simple go/no-go test, do:
If all is well, various elements of the C program will be highlighted/colored. You may not particularly care for the color attributes chosen, but that's configurable (keep reading :-) ). If nothing happened, skip down to the troubleshooting section.
Typing ^X-q each time a new file is opened gets old after awhile. To force the editor to take over this task, add this line to your startup file:
setv $read-hook HighlightFilterMsg
This setting initiates syntax coloring whenever a new file is edited. However, note that the read-hook won't initiate syntax coloring when a buffer's contents change, which brings us to the next topic. HighlightFilterMsg is a wrapper for the macro HighlightFilter, which adds a message saying that it is updating attributes. If you prefer no messages, use HighlightFilter.
It's possible to automatically initiate syntax coloring when the editor detects no active input during a user-configurable interval. If this sounds appealing, add the following to your startup file:
; change autocolor mode value to suit individual tastes
set autocolor=2000
setv $autocolor-hook HighlightFilterMsg
These settings initiate an automatic syntax coloring check whenever 2 seconds of idle time elapses (autocolor's argument is scaled in milliseconds). Note that autocolor won't actually invoke a syntax filter unless it detects a modified buffer.
To disable this feature, set autocolor to 0 (zero).
Note that "autocolor" is a buffer mode and as such, can be enabled globally, but disabled for one or more buffers where coloring is inappropriate. That is, type ":setl autocolor=0" to disable the automatic syntax coloring for a particular buffer.
For obvious reasons, this feature is less "intrusive" on fast hardware. Even on fast hardware, running an external syntax filter can be a little slow. The built-in filters run much faster, fast enough that this combination is not that intrusive. The filters.rc script checks if vile has built-in (or loadable) syntax filters and will turn on autocolor and the $read-hook automatically in this case (with a 5 second idle time). Depending on the speed of your hardware, you may wish to make this shorter.
If autocolor is too slow, you can temporarily disable it by turning the highlighting mode off:
:set nohl
Filters will color text based on the contents of the file COLORDIR/vile.keywords . This file's configuration syntax is described in detail in doc/filters.doc. We'll hit the high points here:
.class <name>:<ACS>
where:
<name> ::= an arbitrary alphanumeric string.
<ACS> ::= { C<hexdigit> | U | I | B | R }
C<hexdigit> ::= internal vile color name
U ::= underline attribute
I ::= italic attribute
B ::= bold attribute
R ::= reverse attribute
An example keyword file might contain:
.class Action:BC2
.class Comment:BC1
.class Error:CA
:.class Ident:R
.class Ident2:C6
.class Keyword:C3
.class Keyword2:BC1
.class Literal:UC5
.class Number:C6
.class Preproc:C2
.class Type:CD
The "Comment" class defines the color attribute applied to a language's comments, which will be rendered in "B"old "C"olor "1". "Literal" applies to string literals, which will be shown as "U"nderlined "C"olor "5". "Keyword" applies to a language's reserved words (e.g., "if", "while", "break"), which will be encoded as "C"olor "3". And so forth. Note that few filters use all of the classes listed in this file.
As should be obvious at this point, color configuration is effected by editing vile.keywords and applying individual tastes and preferences.
For completeness sake, it should be noted that the mapping of language tokens (e.g., "int", "static", "while") to vile.keyword's generic classes occurs in the individual language-specific keyword files. In general, a language-specific keyword file (e.g., COLORDIR/awk.keywords, COLORDIR/perl.keywords, COLORDIR/c.keywords) provides only part of the filter's behavior – much of its action is encoded in its source, which for most filters is written in "flex". It is not expected that users will need or want to edit these files.
From time to time, users upgrade to the latest release of vile. If the above syntax coloring configuration and installation instructions are blindly repeated during an upgrade, your copy of vile.keywords will be overwritten with the corresponding file from vile's distribution. This is not a happy event if you've spent time tweaking this file to suit your tastes (the author speaks from experience). Word to the wise:
Once vile.keywords is edited to your satisfaction, make a backup copy and/or save it under version control!
Try this checklist when syntax coloring doesn't work:
VILE_STARTUP_PATH VILE_LIBDIR_PATH
source "filters.rc" ; quotes matter on win32 hosts
setv $autocolor-hook HighlightFilterMsg
setv $read-hook HighlightFilterMsg
set autocolor=2000
For the most part, when vile visits a file, the correct majormode is attached to the file's buffer and appropriate syntax coloring ensues. But there are times when vile may choose the wrong majormode and/or not specify one at all (the latter case most likely occurs when the file's suffix doesn't match any of the possibilities listed in filters.rc). The result is either inappropriate or no highlighting. In this situation, use the "set-highlighting" macro to explicitly specify the desired majormode.
For example, suppose I'm editing an older copy of a C++ source file called main.cpp, which has been renamed to main.cpp.old . In this scenario, vile will not attach a majormode to main.cpp.old's buffer and consequently will not color the buffer. To set the proper majormode and force syntax coloring, simply type:
:set-highlighting cpp
It's also possible to syntax color Unix man pages, although the procedure is not tied to a majormode. Refer to the help topic entitled 'Filtering "man" pages' for further information.
The editor is capable of spell checking the current buffer (with ispell) and subsequently highlighting all misspelled words in the Keyword class color (as specified in vile.keywords). If this feature sounds useful, then add this line to your startup file:
source "spell.rc"
Spell.rc installs ^X-i as the keybinding that initiates spell checking.
More information on syntax coloring can be found in the file doc/filters.doc, in the vile source directory.
Syntax highlighting applies to buffers which are loaded from files. vile can also generate buffers to show its internal state. Those can be colored using the "extra colors" feature. The feature is called "extra colors" both because these are colors not set via syntax filters, but also because it allows color and attribute combinations not available via the normal mode setting mechanism.
The show-extra-colors command shows the types of things that can be colored, along with their current state, e.g.,
enum default hypertext default isearch default linebreak default linenumber default modeline reverse number default regex default string default warning default
The set-extra-color command sets the colors. It prompts for the name of a type, followed by a combination of color and attributes. Use '+' to join the color and attributes. These are possible commands for setting isearch (the highlighting used for incremental search):
set-extra-color isearch reverse
set-extra-color isearch reverse+blue
set-extra-color isearch blue+reverse
set-extra-color isearch blue+reverse+underline
set-extra-color isearch red
Here is an example of how the various extra colors might be used:
~if &sge &cat $version $patchlevel 'version 9.7f'
~with set-extra-colors
isearch blue+underline
hypertext underline+red
modeline reverse+green
string magenta
regex underline+magenta
number cyan
enum green
~if &sge &cat $version $patchlevel 'version 9.7m'
warning reverse+bold+red
~endif
~endwith
Prior to studying majormodes, it helps to be familiar with the "Editor modes" and "Syntax coloring" topics.
Majormodes are collections of buffer mode values that vile automatically assigns to new buffers. When the vile distribution file "filters.rc" is sourced, it in turn sources "modes.rc", which subsequently defines a significant number of majormodes for various programming languages and file formats. The majormode assigned to a particular buffer is dependent upon two criteria, in the following priority order:
Both suffix and preamble are expressed as regular expressions and examples of each are readily available in modes.rc . Speaking of modes.rc, it becomes obvious from browsing this file that most majormode buffer settings involve specifying appropriate regex patterns for fences and comments.
The syntax for defining a new majormode or overriding an existing majormode is quite rich and fully described in the file doc/modes.doc. Rather than regurgitating the contents of that file here, we'll hit the high points with a couple of examples.
To define a new majormode, add this in your vile startup file:
define-mode <new_majormode_name>
~with define-submode <new_majormode_name>
mode-pathname "<regexp_pattern>" ; see next para
mode-filename "<regexp_pattern>" ; see next para
suffixes "<regexp_pattern>" ; see next para
preamble "<regexp_pattern>" ; see next para
before "<if necessary>"
filtername "<syntax-coloring-filter>"
buffer mode setting#1
buffer mode setting#2
; etc.
~endwith
Selecting file(s) for inclusion within a majormode is a matter of specifying an appropriate regular expression, like so:
| regexp mode name | selection based on |
|---|---|
| mode-pathname | any file component in path |
| mode-filename | leaf filename |
| suffixes | .<file_suffix> |
| preamble | first line of file |
One or more of these regular expressions may be specified within a majormode definition, with selection precedence given in the order listed above.
As an actual example, suppose someone wanted to edit this help file and subsequently submit patches to vile's developers. In the spirit of cooperation, the developers would appreciate changes that were made with the same tabstops and tab insertion policies as used in the existing help file (vile.hlp). Taking a peek at vile.hlp, it can readily be seen that physical tabs are indeed used, with stops apparently set at intervals of 8. Also, it appears that the right margin is set fairly close to 80. To mirror this policy, create this new majormode:
define-mode hlp
~with define-submode hlp
suf '\.hlp$'
ts=8
fillcol=77
tabinsert
filtername 'vile-txt-filt'
~endwith
Now, whenever a file with suffix ".hlp" is edited, it will be colored with vile-txt-filt and physical tabs inserted at multiples of 8.
To override or augment the buffer mode settings of an existing majormode, do this in your startup file:
source "filters.rc"
; ...
define-mode <existing_majormode_name>
~with define-submode <existing_majormode_name>
changed buffer mode setting#1
changed buffer mode setting#2
; etc.
~endwith
For example, suppose it was desirable to edit all text files with ignorecase disabled. This startup file snippet will suffice:
source "filters.rc"
; ...
define-mode txt
~with define-submode txt
ignorecase
~endwith
Once associated, majormode submodes can be setl/unsetl just like regular local buffer modes. But note well that set/unset have no effect on submodes. So, when hlpmode is in effect, this command works:
setl notabinsert
but this command has no effect:
set notabinsert
As added syntactic sugar, majormode submodes may be prefixed with the majormode name and changed like so:
set/setl txt-ignorecase
set/setl hlp-fillcol=60
unset/unsetl txt-ignorecase
unset/unsetl hlp-tabinsert
1) Use the command "show-majormodes" to display the list of majormodes and their associated submodes.
2) Only one majormode can be set for a buffer.
3) To override the majormode that vile assigns to a buffer, use either the set-highlighting macro (defined in filters.rc) or the "setl <majormode_name>" command. Example:
setl cppmode ; <-- force cppmode for current buffer
Both C and C++ use ".h" as an include file suffix. vile's current majormode definitions favor "*.h" for inclusion in cmode (not cppmode), which is not desirable for C++ programmers and/or a C++ project. There are two workarounds:
1) On a project-by-project basis (i.e., developer does not devote all of his/her time to C++ coding), simply add something like this to the vile startup file:
source "filters.rc"
; ...
define-mode cpp
~with define-submode cpp
mode-pathname 'project_root_directory_name/.*\.h$'
~endwith
This change specifies that all "*.h" files beneath a root directory name are presumed to be C++ files.
2) If coding C++ more than C, then make these changes:
source "filters.rc"
; ...
define-mode cpp
~with define-submode cpp
suffixes '\.\(C\|CC\|cc\|cpp\|cxx\|hxx\|h\|hh\)$'
~endwith
This change adds ".h" to the list of C++ files and since vile tests cppmode before cmode, all "*.h" files will now be edited in cppmode.
Long before Tom Dickey added majormodes to vile, there existed "cmode", a feature that included its own builtin tab settings and indentation style (still available today as "cindent"). This older version of cmode served as the precursor for vile's current majormode system.
Today, even if filters.rc is not sourced at runtime, vile includes a builtin majormode called cmode that is defined internally like so:
define-mode c
~with define-submode c
ts=8
sw=8
cindent
cindent-chars ":#"
suffix "<complex_regexp_for_c_c++_file_suffixes>"
filtername 'vile-c-filt'
~endwith
This builtin majormode can produce some surprising results when editing C source files. In particular:
set ts=<val> ; <-- has no effect, use "setl" instead
What's more these settings may be anathema for the coding style in effect for a given software project. Override these settings in the vile startup file to suit your needs/taste, like so:
define-mode c
~with define-submode c
ts=4
sw=4
nocindent
~endwith
When used in conjunction with the vile-manfilt program (supplied as source file filters/manfilt.c), either vile or xvile may be used to filter and view manual pages. xvile will even display (with your font set properly) certain portions of the manual page text in bold or italics as appropriate.
The file macros/manpage.rc (found in the vile source directory, with portions copied below) contains a macro which is bound to ^X-m. It will prompt for a manual page, filter it, attach attributes and display it in the current window. The text of manpage.rc may be either incorporated verbatim into your .vilerc file or may be read from your .vilerc as follows:
source "manpage.rc"
This assumes that you have moved the manpage.rc file to a directory known to vile (automatically handled by "make install" on Unix or, alternatively, by pointing the VILE_STARTUP_PATH env var to the directory where this file resides). If you do all of this but use vile rather than xvile, you will still end up with a legible man page, albeit without the spiffy formatting.
The manual page filtering program may also be used to look at other text formatted with nroff. From the vile source directory, for example, the following command will format and filter the vile manual page (which is nroff source).
:e !nroff -man vile.1 | vile-manfilt
Once loaded, it will look rather funny. There will be Cntl-A characters scattered throughout the text followed by a sequence of digits followed by one or more uppercase letters followed by a colon. These Cntl-A sequences specify how the text following the colon should be attributed. The vile command "attribute-cntl_a-sequences-til" (bound to ^A-A) may be used to format a region of text containing these sequences. To continue our example, the following command will translate this representation of attributed text into one which is more pleasing to look at.
^A-AG
Note that macros/manpage.rc also provides a macro that attaches attributes to any man page displayed in the editor's current buffer.
vile includes several features that enable quick access to many files spread over a directory hierarchy, as described below.
vile provides several commands that manipulate an internal directory stack:
:dirs
:dirs-add dir
:dirs-clear
:popd [ {+|-}n ]
:pushd [ dir | {+|-}n ]
If pushd or popd is successful, a "dirs" is performed as well.
Assume the following directory hierarchy:
root
/ | \
/ | \
lib src include
Assume also that most of the development work takes place in the "src" directory and that this is a C/C++ project.
Once an appropriate tags file has been created in the src directory (using the ctags program), vile's tags interface provides quick access to the most frequently modified project files. But what about the source files in the "lib" and "include" directories? Is it possible for vile's tags interface to access the C/C++ files in the aforementioned directories when the editor's cwd is set as "src"? The answer is an emphatic "Yes". This can be done using at least two different mechanisms.
Assuming the Exuberant Ctags program is available (written by Darren Hiebert), the simplest method is as follows:
1) cd to the project root dir and issue this ctags command:
ctags -R . '*.[ch]' '*.cpp'
This command drops out a tags file in the root directory that includes tags for all three subordinate directories. Repeat this step as necessary whenever significant changes are occur within the project hierarchy.
2) modify the vile startup file (vile.rc or .vilerc) to include this setting:
set tagrelative
set tags="../tags"
vile's tags lookup features now provide one-keystroke access to symbols in all project source files, provided that the editor's current working directory is set as either src, include, or lib.
It's important to note that Exuberant Ctags has been ported to many hosts (including VMS) and supports many languages other than C.
Use this recipe when working with the standard ctags program (available on virtually all Unix hosts):
1) cd to the project root dir and issue this ctags command:
ctags src/*.[ch] src/*.cpp lib/*.[ch] lib/*.cpp include/*.h
this command drops out a tags file in the root directory that includes tags for all three subordinate directories. Repeat this step as necessary whenever the lib or include directory contents change.
2) modify the vile startup file (vile.rc or .vilerc) to include this setting:
set tagrelative
set tags="../tags"
This method achieves the same one-keystroke symbol access as described for Exuberant Ctags.
vile's capture-command (bound to ^X-!) includes an interface to the Unix find command (or equivalent clone) that permits the user to access a large number of files or directories spread across an arbitrarily complex hierarchy. This feature requires a small amount of configuration before it can be used.
To begin with, specify a directory hierarchy via the $findpath state variable using this syntax:
setv $findpath="<dir>[<delim><dir>]..."
where <delim> is ':' on a Unix host and ';' on a win32 host. If this state var is not set, "." is assumed.
Next, use find-cfg mode to enable the traversal feature. This mode's string argument syntax is as follows:
[<recursive_token>][,<nonrecursive_token>[,<option>...]]
where:
<recursive_token> := an ascii character that triggers a
recursive find. The selected token may
not be taken from the character set
defined by isalpha(). To use ',' as a
token, escape it with '\'.
<nonrecursive_token> := an ascii character that triggers a
nonrecursive find–shares the same
semantic restrictions as the
recursive token.
<option> := {d | f}
Note 1: The "d" option specifies that find should restrict its search solely to files of type "d" (i.e., directories). The "f" option adds a "-follow" operand to the commandline, which directs find to follow symbolic links. Note that -follow is appropriate for the GNU tool chain, SunOS v5.7, and possibly other hosts. Check your local find (1) man page for compatibility.
Note 2: An empty string argument disables find-cfg mode.
Note 3: Most versions of find do not support nonrecursive operations. The one known exception is GNU's find.
Assume the same project hierarchy as was used in the description of "Hierarchical tags" above. Assume also that the path to the project root is /local/proj/root and that the vile startup file contains these settings:
setv $findpath="/local/proj/root"
set find-cfg="$,@"
Then consider this command:
^X-!$egrep -n FIXME *.[ch] *.cpp
which spawns this Unix shell command:
find /local/proj/root '(' -name '*.[ch]' -o -name '*.cpp' ')' \
-print | egrep -v '((RCS|CVS)/|/[Tt][Aa][Gg][Ss]$)' | \
xargs egrep -n FIXME
and this win32 shell command:
find /local/proj/root '(' -iname '*.[ch]' -o -iname '*.cpp' ')' \
-print | egrep -vi '((RCS|CVS)/|/tags$)' | \
xargs egrep -n FIXME
The net result is that capture-command has been used to find the string FIXME in all C/C++ source files located in the project hierarchy. The results of this search are placed in the editor's [Output] buffer. Each occurrence of the string can be accessed via the error finder's ^X-^X binding. Note that the above shell commands are crafted to ignore files stored in RCS/CVS directories and to ignore the files created by ctags.
If it's preferable to use a nonrecursive find operation and the GNU find utility is available on your host, you might try this on a Unix host:
setv $findpath="/dir1:/dir2:/dir3"
set find-cfg="$,@"
^X-!@egrep -ni copyright *.txt
which spawns this Unix shell command:
find /dir1 /dir2 /dir3 -maxdepth 1 -name '*.txt' -print | \
egrep -v '((RCS|CVS)/|/[Tt][Aa][Gg][Ss]$)' | \
xargs egrep -ni copyright
Or, correspondingly, on a win32 host:
setv $findpath="/dir1;/dir2;/dir3"
set find-cfg="$,@"
^X-!@egrep -ni copyright *.txt
which spawns this win32 shell command:
find /dir1 /dir2 /dir3 -maxdepth 1 -iname '*.txt' -print | \
egrep -vi '((RCS|CVS)/|/tags$)' | xargs egrep -ni copyright
Of course, if your version of find doesn't support the "-maxdepth" option, this feature won't work. The workaround is simple–upgrade to the GNU version of find.
Suppose all you really desire is access to the names of the directories embedded within a project hierarchy. This might be useful for Perl hackers who want to manipulate a directory's contents with specialized scripts. To obtain this functionality, specify find-cfg's "d" option. As a contrived example:
setv $findpath="/local/proj/root"
set find-cfg="$,@,d"
^X-!$ls -ld
yields this shell command (on a Unix host):
find /local/proj/root -type d -print | egrep -v '(RCS|CVS)/' | \
xargs ls -ld
Filters may be written as either an external program or with the Perl interface. Both the manual page filter and the C program colorizer are examples of external programs which do the filtering. The hgrep.pm perl script is an example of a filter which uses the vile's interface to Perl.
Regardless, the goal of the filter is to embed in the text a control sequences which describe how the subsequent text should be attributed by the vile command
attribute-cntl_a-sequences-til
or, preferably
attribute-from-filter-til
(See above for examples of how to use this command.)
The control sequences take the following form:
^A<Count><Attr>:
<Count> is a sequence of digits representing the number of characters following the ':' to be attributed.
<Attr> is a sequence of characters which indicates how to attribute the required number of characters following the ':'. The following sequences are recognized by vile:
I -- italic B -- bold R -- reverse (or inverse) video U -- underline C<hex digit> -- color number (one of 16) H<command>\0 -- hypertext command M<command>\0 -- meta information (ignored)
The <command> for hypertext commands may be any sequence of characters except for newlines and null characters. A null character must terminate the hypertext command. The command should be a valid vile command such as you might enter into your .vilerc file.
The attribute characters may be used together in any combination. So, for example, you could use the following to make some text appear both bold and italic:
^A15IB:Bold and italic
Vile does not currently supply a builtin key binding for executing hypertext commands. The following macro and key binding will cause the space bar to be bound to a macro which will follow a hypertext link when the cursor is placed on top of it. If no hypertext link is present, then the normal default action of advancing one character to the right is taken:
22 store-macro
~force execute-hypertext-command
~if ¬ $status
~force forward-character-to-eol
~endif
~endm
bind-key execute-macro-22 ' '
[ TODO: Maybe we should just add a little bit of code to make this the default binding for space bar? Or is some other key binding preferable? In any event, it'll only take 7 or 8 lines to do the job... ]
Here is another example, which gives a choice between following a hyperlink, e.g., as embedded in which-source, or showing its content:
bind-key execute-hypertext-command ^X-z
bind-key show-hypertext-command ^X-Z
When using xvile, double clicking on a hypertext link will cause the hypertext command to be executed. If no hypertext command is associated with the text under the cursor, the default action of selecting the word under the cursor will occur instead.
~trace on
or
setv $debug true
To disable tracing, use:
~trace off
or
setv $debug false
Note 1: The list of possible paths is taken from all directories specified in $PATH + $libdir-path.
Note 2: On non-Unix hosts, a file suffix is required (e.g., ":which-exec copy.exe", not "which-exec copy").
Note 3: Specify a numeric argument to force vile to popup a buffer that displays all possible paths (e.g., "2:which-exec fmt"). For example:
Show which executable-paths are tested for:
fmt
("*" marks found-files)
$PATH
/usr/local/bin/fmt
/users/tom/bin/fmt
/users/tom/com/fmt
/usr/sbin/fmt
/sbin/fmt
* /usr/bin/fmt
/bin/fmt
/usr/games/fmt
./fmt
$libdir-path
/usr/lib/vile/fmt
Note 1: The list of possible paths is taken from the same directory hierarchy described in the "Invocation" help topic.
Note 2: Specify a numeric argument to force vile to popup a buffer that displays all possible paths (e.g., "2:which-source vileinit.rc"). For example:
Show which source-paths are tested for:
vileinit.rc
("*" marks found-files)
$cwd
vileinit.rc
$HOME
/users/tom/vileinit.rc
$startup-path
* /usr/share/vile/vileinit.rc
For debugging syntax highlighting, the following also are useful:
If you are using xvile under X11, the following additions are available:
Selections may be made by holding button one down and "wiping" with the mouse. Release of the mouse button will cause the selection to be yanked and made available (if desired) for pasting. The region selected may be forced to be rectangular by holding the control key down while wiping with button one depressed. If the wiping motion goes out of the current window, text will be scrolled in the appropriate direction if possible to accommodate selections larger than the window. The speed at which the scrolling occurs will increase with the passage of time making it practical to select large regions of text quickly.
Individual words or lines may be selected by double or triple clicking.
As described below in the "Scrollbars" section, the buttons are modified by the control key as follows, when used on a scrollbar:
Ctrl-Button-1 splits the clicked-on window into two
windows.
Ctrl-Button-2 deletes the clicked-on window.
Ctrl-Button-3 makes the clicked-on window the only window.
Areas of selected text can be operated on with any vile operator command, in conjunction with the special "motion" command '^S', which applies the operator to the selected region. For example, after selecting text with the mouse, it can be converted to uppercase with ^A-u^S. Remember that some operators (e.g. the shell-filtering operator, '!') are only capable of working on full lines of text.
Data may be exchanged between many X applications via the PRIMARY selection. This selection is set and manipulated as described in the above section entitled "Mouse Buttons".
Other applications, most notably OpenLook applications, use the CLIPBOARD selection to exchange data between applications. On many Sun keyboards, selected text is moved to the clipboard by pressing the "Copy" key and pasted by pressing the "Paste" key. If you find that you can not paste text selected in xvile in other applications or vice-versa, it may well be that these applications use the CLIPBOARD selection instead of the PRIMARY selection. (The other mechanism used among really old applications involves the use of a ring of cut buffers.)
xvile provides two commands for manipulating with the clipboard. These are copy-to-clipboard and paste-from-clipboard. When copy-to-clipboard is executed, the contents of the current selection are copied to the special clipboard kill register (denoted by ';' in the register list). When an application requests the clipboard selection, xvile gives it the contents of this kill register. The paste-from-clipboard command requests clipboard data from the current owner of the CLIPBOARD selection.
Users of Sun systems may want to put the following key bindings in their .vilerc file in order to make use of the Copy and Paste keys found on their keyboards:
bind-key copy-to-clipboard #-^
bind-key paste-from-clipboard #-*
The X toolkit version of xvile provides default translations similar to the translations for scrollbars found in the Athena widget set. (If you know how to use xterm's scrollbars, you know how to use these scrollbars.) Button one scrolls forward. Button three scrolls backward. The amount of scrolling obtained by these buttons depends on the position at which they were pressed on the scrollbar. Clicking near the top of the scrollbar will scroll the text by a small amount which may be as little as one line. Clicking in the middle will scroll by about half a page. Clicking near the bottom will scroll by a larger amount up to a whole page. Holding either one of these buttons down will cause repeated scrolling.
If simply pressed and released, button two will set the position in the buffer to a position proportional to the location of the pointer on the scroll bar. Button two may be held down to "drag" the slider from one place to another causing text to scroll continuously.
The Motif and OpenLook versions provide scrollbars from their respective widget sets. Both versions have a slider indicating the position of the window over the buffer. OpenLook's slider is fixed in size with little arrows at the top and bottom of the slider. Pressing on one of these arrows will cause scrolling in the appropriate direction. The slider may be "grabbed" and moved by pressing and dragging the middle portion between the arrows. Motif's slider is solid with size varying to indicate the size of the window with respect to the size of the buffer. Any portion of it may be grabbed for movement. There are little arrows at the top and bottom of the scroll bar which may be clicked upon to cause scrolling by one line. In both of these widget sets, clicking on the scrollbar either above or below the slider will cause scrolling by a full page. OpenLook has two additional control areas; the buffer position may be set to either the beginning or end of the buffer by pressing on one of the little rectangular areas at either the top or bottom of the scrollbar.
In all versions built with scrollbars enabled, you can resize windows by moving the border between corresponding scrollbars (with the mouse). The X toolkit version is probably the most functional, with the windows being continuously resized as the mouse is moved. The OpenLook and Motif versions wait until after a position is selected to resize the windows. The OpenLook version is perhaps the least functional; there is no visible indication (other than the position of the mouse pointer) to indicate where the new border will be.
Splitting and deleting of windows may also be done with the mouse. In each case the action is selected by pressing one of the mouse buttons over a scrollbar with the control key held down. Button one (with the control key held down) will split the scrollbar and the corresponding vile window with the new border at or near the mouse cursor. Button two (with control key) will delete the scrollbar and corresponding window. Button three (with control key) will make the corresponding window the only window.
-fn fontname
|
Font to use (or -font). |
-rv
|
Use reverse video (also -reverse). |
+rv
|
Don't use reverse video. |
-display disp
|
Display to run xvile on. |
-fg color Foreground
|
color (or -foreground). |
-bg color Background
|
color (or -background). |
-bd color Border
|
color (or -bordercolor). |
-name name
|
Application name used for resource lookups. |
-title name
|
Name to be displayed in titlebar. |
-geometry geom
|
Initial window dimensions in columns and rows. |
-iconic
|
Start xvile iconified. |
-xrm Resource
|
Specify or change an X resource internal to xvile. |
-class name
|
Class name used for resource lookups. |
-fork
|
to spawn xvile immediately on startup |
+fork
|
to force xvile to not spawn on startup |
-leftbar
|
Put scrollbar(s) on left. |
-rightbar
|
Put scrollbar(s) on right (default) |
Some systems and/or some shells and display managers seem to want xvile to run in its own process group, to help isolate its signals and actions from the signals and actions of the parent process (i.e. the shell or window manager that starts xvile). xvile can be forced into its own process group with the "new-process-group" command, which one would put in the .vilerc file. Using this will cause a call to "setpgrp()" or "setsid()". This behavior is not the default because a) it can't be undone, and b) it seems undesirable on some systems, in that xvile cannot be suspended and put in the background after startup if it's in its own group.
Additionally, if given a count as argument, this command will cause xvile to fork(), and the parent to exit before the new process group is set by the child. This will further isolate it from its process environment (and in fact will move xvile into the background if started from the shell).
The "new-process-group" command has no effect in non-X11 versions of vile.
| Name | Description |
|---|---|
| font | Font to use. |
| geometry | Window dimensions in characters. |
| iconName | Name of icon for decorating window frame. If set, this overrides the compiled-in pixmap which is used for the window manager's hint of the icon pixmap. |
| charClass | Character classes for multiple click selections. The format is identical to that of xterm(1). |
| multiClickTime | How long between clicks (in milliseconds) to be accepted as a multi-click. |
| foreground background |
Foreground/Background color of the main xvile text area. |
| cursor.foreground cursor.background |
Foreground/Background color of the cursor. By default the cursor location is indicated by inverting the foreground and background colors of the cell the cursor is over. Thus the color of the cursor will vary depending upon location. Use of these subresources will cause the cursor to maintain constant coloration of the user's choosing, and may make it easier to see when it appears in a "highlighted" or "selected" area of text. |
| menuBackground menuForeground |
(Compile-time optional feature) resources for setting the background and foreground colors of menubar and pulldown menus. |
| modeline.focusForeground modeline.focusBackground |
Foreground/Background color of the mode line corresponding to the window with focus, i.e. the "current" window. |
| modeline.foreground modeline.background |
Foreground/Background color of mode lines corresponding to windows without the keyboard focus. modeline.background is also used for the scrollbar borders and resize grips. |
| forkOnStartup | If true, xvile forks after initialization. |
| focusFollowsMouse | If true, the "current" window is the window inhabited by the mouse; no clicking is necessary to change windows. |
| pointer.foreground pointer.background |
Foreground/Background color of the pointer. |
| pointer.normalShape pointer.watchShape |
Set the shapes for the normal and watch pointers respectively. |
| scrollbarOnLeft | Either true or false; control the placement of the scrollbars. By default, scrollbars are placed on the right. |
| scrollbarWidth | An integer indicating the width of the scrollbar. |
| scrollbar.foreground scrollbar.background |
Foreground/Background color of the slider or one of the colors of the slider if a stippled pixmap is used. To force the slider to be only the foreground color, you should set sliderIsSolid to true. (X toolkit version only) |
| scrollbar.sliderIsSolid | If false, indicates that the stippled pixmap should be used to simulate grey. This will be best on monochrome displays. True works better for color displays. True indicates the slider will be displayed in the foreground color, shaded to look three-dimensional, if possible. (X toolkit version only) |
| scrollRepeatTimeout | Amount of time in milliseconds to wait initially before repeating scroll when button one or three are held down. (X toolkit version only). |
| scrollRepeatInterval | Amount of time to wait between repeating subsequent scrolls. This parameter is also used for controlling the speed at which selections are scrolled. |
| selection.foreground selection.background |
Foreground/Background color of the selection regions. "foreground" is the color that the text is displayed in. |
| persistentSelections | If true (the default), highlighting of the selection will persist even when button one is pressed to set the cursor position. A false value will behave more like other X applications in which display of the selection is lost as soon as button one is pressed. |
| selectionSetsDOT | If false (the default), the cursor will be restored to its previous position prior to making the selection. If true, the cursor will be positioned at the location of the mouse at the end of making a selection (usually at either the start or end of a selection). |
| blinkInterval | An integer indicating the time in milliseconds to wait before blinking the cursor. A positive value will cause the cursor to always blink. Setting blinkInterval to zero will cause the cursor to never blink which may be useful on some display servers connected to very slow networks. The disadvantage of setting it to zero is that it is sometimes hard to tell where the cursor is when situated at the boundary of a highlighted region. A negative value (which is the default) will cause the cursor to blink only when situated in a highlighted region such as a selection. This will make the cursor visible no matter where it is. |
| color.fcolor0, color.bcolor0, ..., color.fcolor15, color.bcolor15 |
When doing text attribution with the "attribute-cntl_a-sequences-til" command (bound to ^A-A), the attribute may be of the form "Cn", where 'n' is a hexadecimal digit. This digit picks one of the 16 fcolor/bcolor pairs set up in the color subresource. For example, if the buffer contained the text: ^A6C3:foobar then after the ^A-A command was applied, the leading "^A3C3:" would be gone, and the word "foobar" would appear in the foreground and background colors specified by color.fcolor3 and color.bcolor3. The fcolorN resources have default values corresponding to the ANSI convention, while bcolorN default to the window background. If you wish to set bcolorN for special effect, you should add this to your .vilerc file set bcolor=fcolor to tell xvile to use the bcolorN resources when displaying attributed text. Otherwise, setting bcolor will change the window background, as in the termcap and similar versions of vile. |
| menuHeader menuEntry |
The names given to the menu header and entries, respectively. |
| menuHeight | resource controlling the Athena menu-height |
| openIm | true if input method should be opened (default: true) |
| inputMethod | input method to use (default: "") |
| preeditType | pre-edit type (default: "OverTheSpot,Root") |
| wheelScrollAmount | Amount to scroll for a wheel mouse, per button-press. |
You may or may not want to use the following as a starting point for the "XVile" section of your .Xdefaults or .Xresources file. If you have a monochrome display server, you will probably not want to use any of the color specifications. You may, however, wish to set up a blinking cursor, using "blinkInterval" (see above).
XVile*font: -*-courier-medium-r-normal-*-*-*-75-75-m-70-iso8859-*
XVile*geometry: 80x54
XVile.background: darkslategrey
XVile.foreground: honeydew
XVile.scrollbar.foreground: firebrick2
XVile.scrollbar.sliderIsSolid: true
XVile.selection.background: aquamarine4
XVile.selection.foreground: honeydew
XVile.cursor.background: yellow
XVile.cursor.foreground: darkslategrey
XVile.modeline.Background: steelblue
XVile.modeline.foreground: darkslategrey
XVile.modeline.focusForeground: yellow
The $font variable corresponds to the X11 font resource. To change the font on the fly, use the ':setv' command to set the $font variable, with ":setv $font <fontname>". The actual font used depends upon how xvile is built:
If xvile uses bitmap fonts, fontname is either an XLFD string which is a dash-separated list of attributes, or an alias to one of the known X11 fonts.
xvile derives the names of bold and italic fonts from the fontname string by changing those attributes. The fontsize is one of those attributes, but is less readily changed (bitmap fonts cannot be scaled nicely).
Users of xvile will find that the italic font in particular is not always available with the font that they've chosen (or have had chosen for them). If an italic font is unavailable, xvile will underline text which is meant to be italic. The program xfontsel is quite useful for determining which fonts are available on your display server and whether there are corresponding bold and/or italic fonts available.
If xvile uses TrueType fonts, the fontsize can be given as the second field in a comma-separated list, e.g., ":setv $font monospace,18". To change only the size, omit the font family name, e.g., ":setf $font ,22".
In this case, xvile uses the Xft and fontconfig libraries to derive bold and italic fonts.
Here are some tips on using xfontsel to find an appropriate font.
This will be the font to use. xvile will be attempt to get the italic font when needed by substituting either "o" or "i" for the "r".
If the above seems too tedious, you can just try the following font which (on many display servers) is pretty close to the size of the default font that xvile will start up with.
-*-courier-medium-r-*-*-*-*-*-*-*-70-*-*
You can try it out by issuing the appropriate "set font" command from xvile. For longer term use, you will probably want to put it in your .Xdefaults file. It will look something like this:
XVile*font: -*-courier-medium-r-*-*-*-*-*-*-*-70-*-*
You may also set the font from your .vilerc file. This is not recommended, however, as you lose the ability to choose a different font from the command line or resource file. It may also cause the xvile window to be unnecessarily resized during initialization.
The .vilerc file is called vile.rc under DOS.
vile is perfectly happy (and even tries very hard) to use the UNIX-style "forward-slash" ('/') as a path delimiter. Entering the "backslash" ('\') will work, but you should be aware that vile uses this character as an escape mechanism for entering special characters (e.g. "\t" for TAB) in strings. As an example setting "tags" to "tags ..\tags" will not have the intended result. Instead, use "tags ..\\tags" or better, "tags ../tags".
vile should leave your screen in the mode you're in when you enter it, unless you explicitly change it to a different mode with a "set sres=" line in your vile.rc, or if you use a command line option to change it. Command line options consist of a dash followed by one of the following selectors (these are the same values that can be assigned to "sres"). These values are supported by the DOS (borland.c) terminal driver: "2", "25", "4", "43", "5", "50", "6", "60"
If you shell out in 50 line mode, make sure you are in 50 line mode before you exit the dos shell, otherwise you end up with a 50 line edit window with only the top 25 displayed.
The vile.rc file can be located in the same directory as your binary executable, since vile searches the $PATH for this file.
All file globbing, including from the command line, is done using UNIX shell-style wild-carding conventions.
The expansion of the ':' character in user input, which normally expands to the "word under the cursor", is suppressed for DOS, due to the conflict with the drive-specifier syntax (e.g. "c:\foo"). The character '&' may be used for this instead.
In any version of vile there is a command, "set-dos-mode", which will a) strip all carriage-return ('^M') characters from the ends of lines in the buffer and b) set the "dos" mode so that carriage returns are appended when the file is written. There is also a corresponding "set-unix-mode" command, which strips carriage returns, and forces "nodos" mode, so that they don't come back when you write the file. In both cases, "dos" mode becomes a so-called "local" mode, so that the rest of your buffers will be unaffected. See also the discussion of "recordseparator" mode.
The .vilerc file is called vile.rc under VMS
Reading from a pipe works; writing to a pipe is not implemented.
As is true for DOS, the expansion of the ':' character in user input is not supported due to conflicts with filename syntax delimiters. Use '&' instead.
vile recognizes either VMS- or UNIX-style pathnames and '~' is supported as a shortcut for SYS$LOGIN (e.g., :e ~/login.com). However, filename completion only works for UNIX-style pathnames, since those allow us to implement directory and filenames in the same syntax.
CDPATH directory lists are delimited with a comma and only the following components may be included:
Example:
$ CDPATH :== dev$diska:[home],rooted$build_dir:
vile accepts these command-line options in addition to the standard ones:
| Option | Description |
|---|---|
| -80 | force 80-column mode (N/A for VT52 terminals) |
| -132 | force 132-column mode (N/A for VT52 terminals) |
| Name | Description |
|---|---|
| allversions | Show all versions of files in response to filename completion or wildcards on the command line. Normally this is off. (U) |
| flash | This feature is implemented by setting the screen video to reverse color and then normal. If this sequence of changes is incompatible with your terminal preferences, avoid this mode and use vtflash instead. |
| record-format | Specify format of files that vile writes. If undefined, vile will attempt to use the format of an older version of the file, or "stmlf" if none exists. (B) |
| record-attrs | Specify record attributes of files that vile writes. If undefined, vile will attempt to use the format of an older version of the file, or "cr" if none exists. (B) |
| record-length | Maximum record size, used if record-format is "fixed" or "vfc". (B) |
| Name | Description |
|---|---|
| $sres | Switch between 80- and 132-column screen resolutions by setting this variable to either NORMAL or WIDE (e.g., :setv $sres=wide). |
With respect to VT100 and later terminal types, the editor assumes a vt220 keyboard and maps special keys to their closest vile counterpart (e.g., "Remove" mapped to vile's "Delete"). Some vt220 keyboard special keys have no obvious counterpart, in which case, these mappings apply:
PF1-PF4 => F1-F4, Help => F15, DO => F16.
The editor may be invoked/built as a console or GUI application. The former is known as vile.exe and the latter as winvile.exe . For the remainder of this section of the help file, a generic reference to "vile" refers to both the console and GUI editor, unless otherwise stated.
The Win32 version of vile supports almost all of the features and changes listed directly above in the section entitled "DOS specifics", with the exception that the editor's screen resolution cannot be changed using explicit -43, -50, etc. command-line switches or via the sres command.
Winvile accepts these command-line options in addition to the standard ones:
| Name | Description |
|---|---|
| -fn <fontspec> | Initial font (or -font). The "Winvile Font" section below describes <fontspec> syntax. |
| -geometry <C>x<R> | Initial window dimensions in Columns and Rows (for example "-geometry 80x30"). Be aware that the specified geometry may not exceed the bounds of the current desktop screen. Note also that $pagelen and $pagewid may be used to change winvile's dimensions. |
| -i | Check if the remainder of the command-line (after this option) is a readable filename which may contain embedded blanks. If so, change current directory to match this filename. This is used to make shortcuts such as "Send To" work nicely. |
Vile accepts these additional command-line options:
| Name | Description |
|---|---|
| -console | Start editor in a new console environment if stdin is redirected (i.e., input is taken from a redirected file or from a pipe). If this option is not set when stdin is redirected, console mouse features are unavailable (this problem is most often encountered on a Windows NT host). |
Internally, vile uses two radically different mechanisms for piping data to and from the shell. One mechanism uses temporary files and the other simply calls native Win32 services. This dichotomy exists because the NT shell (cmd.exe) handles native pipes cleanly, but command.com, Microsoft's 16-bit Win9X/WinME shell, does not. The mode variable w32pipes determines which mechanism is used.
On WinNT/Win2K hosts, w32pipes is set by default and vile's pipe operations are implemented via Win32 services. On Win9X/WinME hosts, this mode is disabled by default and the editor falls back to temp files. Take note that 32-bit shells (e.g., Cygwin's bash, MKS's shell) properly handle native pipe operations on Win9X/WinME hosts. In that context, it's appropriate and highly desirable to manually enable "w32pipes" (e.g., "se w32pipes").
| ******* Warning ******** |
|---|
| If w32pipes is enabled and command.com initiates a pipe I/O transaction on behalf of the editor, vile will almost certainly hang. See the "Shell" topic below to learn how to specify the editor's default shell. |
vile recognizes either DOS- or UNIX-style pathnames and '~' is supported as a shortcut for $HOME (e.g., :e ~/vile.rc).
CDPATH directory lists are delimited with a semicolon.
When a filter, pipe, or explicit shell command requires execution of an external process, vile invokes an instance of the shell specified in the $COMSPEC environment variable. This default may be overridden by setting $shell from within vile.rc . Example:
set-variable $shell 'c:\usr\binw\sh.exe'
As is true on other hosts, external processes are normally started under the control of a shell. To forego the shell entirely, prefix the command string with "start ". Example:
:!start calc # start the windows calculator
Finally, it may be necessary to pass one or more flags to the shell invoked via the :sh command (e.g., force execution of a special login script). Passing such flag(s) via $shell is not a workable solution. Instead, use a macro similar to the following that supersedes the builtin :sh command:
store-procedure sh
; pass -L (login) flag to MKS shell, assumes sh is
; reachable from $PATH
~local %sh
setv %sh="sh -L"
~if &seq $progname "winvile"
1 shell-command &cat "start " %sh
~else
1 shell-command %sh
~endif
~endm
In the example, the "1" preceding "shell-command" tells winvile to suppress the
press any key to continue
prompt which it would normally use when the command completes. Without the prompt, the console window which winvile opens to run a shell command will close by itself.
Using Cygwin's bash as vile's shell works well, with one exception. When console vile is invoked from a bash command line, typing ^C or Control+Break within the editor causes an immediate exit (no data saved). As it turns out, bash's signal handling is crafted to work best with other Cygwin programs (ls, wc, etc.) and not with native Win32 apps. A simple workaround is as follows:
function vile
{
sh <<- ENDIT-
vile $@
ENDIT
}
When console vile is subsequently invoked from a bash command line, the editor will be started by sh, which does not suffer from the problem described above. The only drawback with this solution is that $@ splits filenames containing embedded spaces.
Selecting and dragging with the left mouse button yanks text to the unnamed register. Press a control key during the selection to sweep out a rectangular region. Paste the selected text using the second (middle) mouse button. Clear a selection by clicking on a modeline.
Resize a window by dragging its modeline up/down.
Change vile's window focus via left mouse button clicks (when multiple windows are displayed).
Select individual words or lines with a double or triple click.
Note that console vile has zero mouse functionality if the parent command prompt window (aka DOS box) is configured with QuickEdit Mode enabled. QuickEdit is accessed like so:
system menu->Properties->Options Tab
Pressing the right mouse button pops up a menu of editor commands. These are predefined:
| Menu entry | Description |
|---|---|
| Open | executes the "winopen" command (described below). |
| Save As | executes the "winsave" command (described below). |
| CD | executes the "wincd" command (described below). |
| Favorites | executes "winopen $favorites", which starts a common open dialog box that browses the Windows Favorites folder. This feature is especially useful when folder shortcuts are added to the Favorites folder via the Windows Explorer's "Add To Favorites" feature. Once folder shortcut(s) have been created in this manner, winvile's "Favorites" menu provides two-click access to the contents of any local or network-based folder. |
| Font | described below. |
| Menu | disables the popup menu and instead transforms the right mouse button into a hot key that copies the contents of the unnamed register to the clipboard. When the popup menu is disabled, selection with the left mouse, followed by a right mouse click, provides a quick means of copying highlighted blocks of text to the clipboard. |
| Undo | Bound to undo-changes-backward. |
| Redo | Bound to redo-changes-forward. |
| Cut | deletes current text selection into unnamed register and copies same to clipboard. |
| Copy | copies the current text selection to both the unnamed register and the clipboard. |
| Paste | pastes clipboard contents (if text) into current buffer. |
| Delete | deletes current text selection into unnamed register. |
| Select All | selects all text in the current buffer. |
The first six popup menu entries are added to the system menu (in the upper left corner of the window). The system menu also includes:
There are several ways to copy to/from the clipboard:
Some examples, assuming <CI> => Ctrl+Insert and <AI> => Alt+Insert:
4yy<AI> ;copy 4 lines from unnamed reg to clipboard "a<CI> ;copy register 'a' to clipboard "b<CI> ;copy register 'b' to clipboard <CI>3w ;copy 3 words to clipboard
The swap-clipboard-keys command swaps the commands bound to Ctrl+Insert and Alt+Insert.
Winvile may be invoked as an OLE automation server and thereafter controlled by an OLE client. Refer to the file doc/oleauto.doc for further details. Additionally, the OLE client "visvile.dll" provides a mechanism for substituting winvile as the default Developer Studio editor. Refer to the file doc/visvile.doc for detailed information.
Winvile's font may be set via a command-line switch or from within the editor by modifying the built-in $font state variable. In either case, a <fontspec> string describes the desired font, where:
<fontspec> :== [<face>,]<size>[,<style>]
<face> :== font-name
<size> :== point size (as an integer)
<style> :== { bold | italic | bold-italic }
Note 1: if <style> is unspecified, "normal" is assumed.
Note 2: if <face> contains a comma, escape it with '\'.
Note 3: if <face> is omitted, the current font is modified.
Note 4: if <face> contains spaces and the font is set from the command-line, delimit <fontspec> as appropriate for the current shell/desktop environment.
Note 5: <face> must be fixed pitch. To obtain a list of all fixed pitch fonts on the current win32 host, invoke winvile and browse the "Font" dialog box accessible from the system menu (accelerator key is ALT+<space bar>+f).
Cmdline Examples Internal Examples **************** ***************** -fn 'Letter Gothic,8' :setv $font r_ansi,7 -font r_ansi,8,bold :setv $font 8 Vile.rc Example ***************
~if &sequal $progname "winvile"
set-variable $font "courier new,8"
~endif
Winvile uses the system registry to store persistent user
settings. If you have specified that it is installed for all
users, then the installer creates the key VI Like
Emacs under
otherwise, under
HKEY_LOCAL_MACHINE\Software
HKEY_CURRENT_USER\Software
In either case, winvile looks for information from these keys
under its VI Like Emacs key:
Environment
MRUFiles
MRUFolders
Data under MRUFiles and MRUFolders
is maintained by winvile when the corresponding mode recent-files or recent-folders is enabled by setting
it to a nonzero value.
winvile looks for environment variables by first using the
standard getenv, and if that returns nothing, checks
its analogous Environment key in the registry.
winvile uses the registry in this way because it is unreliable
for installers to set environment variables directly on
Windows.
These environment variables may be initialized by the winvile installers:
These environment variables are also useful in winvile:
set-rgb-palette red 200 0 0
With respect to console vile, this string either specifies a fixed, block cursor height or else sets the block cursor heights in the editor's insertion and command modes. Argument syntax:
"<fixed_block_height>" or "<insmode_height>,<cmdmode_height>"
The valid range of <fixed_block_cursor_height> is 0-100 (%). Specifying 0 reverts to the cursor height in effect at editor invocation. The valid range of <insmode_height> and <cmdmode_height> is 1-100.
With respect to winvile, this string specifies an integer in the range 0-2, which selects one of the following styles:
0 -> fixed block cursor
1 -> cmd mode = block cursor
ins mode = vertical bar
2 -> cmd mode = vertical bar
ins mode = block cursor (U)
Some vile commands and modes apply only to winvile and some only to console vile. If you plan to run both winvile and console vile in the context of a single startup file, you'll need to include code similar to this in vile.rc:
~if &sequal $progname "winvile"
set-variable $font "r_ansi,8"
setv $pagelen=39
set icursor="1"
; etc
~else
set icursor="35,100"
; etc
~endif
Of course, this really isn't vi. Some of the following differences deserve changing, others do not.
The parser for the ':' commands is not very vi-like. For instance, ":e" will prompt you for a file name. Most commands remember their last argument, and will present it as the default reply to their prompt.
The backspace, line kill, word kill, job control, etc. characters are not rebindable. They are, however, read from the tty settings on startup.
There is no expansion of ! in filenames. It is expanded in shell escapes, so the command ":!!" does rerun the previous shell command. Occurrences of '#' and '%' are recognized and expanded to the previous or current filename.
Paragraph and section boundaries, for the {, }, [, and ] commands are configurable, but may not exactly match those in vi. They are expressed via regular expressions. The default regular expressions are quite complex, to support the traditional nroff and troff boundaries. If you are just editing code, you may want to replace them:
; set paragraph and section r.e.s for speed on C/C++/perl code.
set paragraphs=^$
set sections=^[{^L]
There is no special lisp support. But then, when was the last time you heard of a lisp programmer that used vi?
Of course, ex and open mode aren't there. (Too bad. I'd love to have a companion editor called "exile".)
Most, but not all, of the word-motion-with-operator and end-of-line anomalies have been recreated. One missing anomaly: In vile, "dw" on the last word of a line ending in whitespace deletes the trailing whitespace. vi does not delete the whitespace.
In the real vi, the '_' command is a little-used motion command, which moves the cursor to the start of the Nth next line, where N is the argument given, less 1. So '2_' takes you to the start of the next line. Primarily intended for use in an operator context, as in "2d_", it is always exactly equivalent in those cases to "stuttering" the operator, as in "2dd". Most people know about and use the stuttered form, so in vile, the '_' command is used by default for buffer history. If the regular vi behavior is desired, put the following in the .vilerc file:
bind-key whole-lines _
Here's a sample .vilerc, to help get you started with the syntax and style of vile macros:
source vileinit.rc
set autoindent
set fillcol 75
; sitting on a brace, run the C code block through indent
1 store-macro
write-file
filter-til goto-matching-fence "indent -st"
~endm
; format the current paragraph
2 store-macro
previous-paragraph
filter-til next-paragraph "/usr/ucb/fmt"
~endm
; put 'fprintf(stderr,"\n");' into the file, and
; position the cursor to add to the string
3 store-macro
~force next-line
beginning-of-line
insert-string "fprintf(stderr, \"\\n\");\n"
; six back, because it counts the newline
6 backward-character
insert-chars
~endm
; insert '> ' in front of every line from here til the end
; (this works because without argument, the default action
; for "goto-line" is to go to the end of file.
4 store-macro
substitute-til goto-line "^" "> "
~endm
; spelling keystroke: write the buffer, invoke ispell, and force
; it to be read back in.
2 store-macro
~local $warn-reread
write-file
; suppress "press return" with "1" argument to shell-command
1 shell-command &cat "ispell " $cfilname
; suppress reread warning
set nowarn-reread
replace-with-file $cfilname
~endm
bind-key execute-macro-2 #I
; the next three give more mnemonic window commands
bind-key next-window ^N
bind-key previous-window ^P
bind-key split-current-window ^T
bind-key execute-macro-1 ^A-C
bind-key execute-macro-2 ^A-F
bind-key execute-macro-3 ^A-K
bind-key execute-macro-4 ^A-M
vile will determine the window size in one of three ways: first it will ask the tty driver (using a TIOCGWINSZ ioctl call under UNIX). Failing that, it will use the LINES and COLUMNS environment variables. As a last resort it will use the size specified in the TERMCAP entry corresponding to the TERM variable. In addition, vile will attempt to support the SIGWINCH signal, which allows it to track changes to the size of the window in which it is running.
If scrolling is really slow, or really ugly (the status line hops around a lot), and you're using a vt102 or compatible terminal that you think should be able to scroll okay, then the problem is almost certainly your termcap entry, which probably doesn't describe scrolling regions adequately. Most standard termcap entries are insufficient. The standard "xterm" entry on many systems falls into this category, and vile contains code that, as a special case, will augment an "xterm" entry with the codes needed for scrolling regions.
In any case, here's a termcap entry that should work:
dy|vt102|vt-102|dec vt102:\
:do=^J:co#80:li#24:cl=50\E[;H\E[2J:\
:le=^H:bs:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\
:ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\
:md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:is=\E[1;24r\E[24;1H:\
:rs=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:ks=\E[?1h\E=:ke=\E[?1l\E>:\
:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:\
:ho=\E[H:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:pt:sr=5\EM:vt#3:\
:sc=\E7:rc=\E8:cs=\E[%i%d;%dr:vs=\E[?7l:ve=\E[?7h:
The crucial entries are cs and sr – without both of them, vile will attempt to use dl and al, and will scroll by deleting and inserting a block of lines, giving the ugly behavior you're probably seeing. If you define PRETTIER_SCROLL when building vile, it will alternately delete and insert lines, instead of deleting them all and then inserting them all. This makes it look a little better, but it's slower.
Here is the terminfo entry equivalent to the above termcap entry:
vt102|vt-102|dec vt102,
xon,
cols#80, lines#24, vt#3,
bel=^G, blink=\E[5m$<2>, bold=\E[1m$<2>,
clear=\E[;H\E[2J$<50>, cnorm=\E[?7h, cr=\r,
csr=\E[%i%p1%d;%p2%dr, cub1=\b, cud1=\n,
cuf1=\E[C$<2>, cup=\E[%i%p1%d;%p2%dH$<5>,
cuu1=\E[A$<2>, cvvis=\E[?7l, ed=\E[J$<50>,
el=\E[K$<3>, home=\E[H, ht=\t, ind=\n,
is2=\E[1;24r\E[24;1H, kbs=\b, kcub1=\EOD, kcud1=\EOB,
kcuf1=\EOC, kcuu1=\EOA, kf1=\EOP, kf2=\EOQ, kf3=\EOR,
kf4=\EOS, rc=\E8, rev=\E[7m$<2>, ri=\EM$<5>,
rmkx=\E[?1l\E>, rmso=\E[m$<2>, rmul=\E[m$<2>,
rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h, sc=\E7,
sgr0=\E[m$<2>, smkx=\E[?1h\E=, smso=\E[7m$<2>,
smul=\E[4m$<2>,
(last updated Jan, 2000)
Since version 6.1, Tom Dickey has been maintaining the "official" source tree, and release responsibilities. Paul Fox maintains the mailing lists.
This code has been written by a lot of people, with help from a lot more sending in bug reports, fixes, and suggestions. The authors of vile are Tom Dickey (dickey@invisible-island.net) and Kevin Buettner (kevin@buettner.to) and Paul Fox (pgf@foxharp.boston.ma.us).
Names appearing within comments in the micro-Emacs source code are: Dave Conroy, Daniel Lawrence, John Gamble, Roger Ove, Dana Hoggatt, Jon Reid, Steve Wilhite, George Jones, Adam Fritz, D.R.Banks, Bob McNamara, and Brian Straight. Dan Lawrence, in particular, did a huge amount of work on the code on which vile is based. vile re-implements and extends many features inspired by his work.
Throughout the years, Tom Dickey has contributed many code improvements and features, and has stabilized vile on both VMS and DOS. After taking over official maintenance duties, Tom coded winvile, added majormodes, added 16-color support, and implemented the majority of the current syntax coloring infrastructure. On an ongoing basis, Tom continues to fix bugs and provide the drive and energy that pushes out one release of the editor after another–no small feat for a product that's supported on multiple hosts.
Kevin Buettner has contributed lots of changes for X11 Toolkit support, as well as the bulk of the selection and video attribute mechanisms, and the bulk of the :map command. Kevin also added autocoloring and a Perl interface to the editor. Rick Sladkey has done great stuff making vile work correctly in Win32 environments, something I might not have done for a long time. Some of the "ex" code is by Steve Kirkendall, author of the vi work-alike "elvis". The regular expression code and documentation is by Henry Spencer. Dave Lemke contributed code for new features, including the original native X11 support. Eric Krohn has done some excellent testing and enhancement. The implementation of rectangles and their operations was inspired by code from the 'notgnu' editor, by Julie Melbin. Patches to support OS/2 came from Charles Moschel and for Windows/NT from Joe Greer and Clark Morgan. Ed Henderson gave us wvwrap, as well as several other useful patches. Chris Coppick created Vileserv. Alex Wetmore contributed stored procedures and vile's initial btree interface (the latter later rewritten by Tom). Brendan O'Dea closely monitors the Perl API, as well as contributing Perl updates. Brendan also added the machinery for binding vile commands to Perl subroutines. Better still, he also found a way to bind operators and motions to same. Kuntal Daftary added several Perl modules. Clark Morgan and Greg McFarlane seem to run full regression tests on each new release, and always seem to find something to report. In addition, Clark regularly updates and corrects the documentation left as an afterthought by the rest of us. Sean Ahern is also always dependable for finding a bug or two per release. The reference.doc file supplied with Bram Moolenaar's excellent Vim editor was useful in unraveling some of the less obvious parts of :map functionality. In addition, his implementation of digraph insertion was used directly in the creation of digraphs.rc. Thanks to Jukka Keto for contributing the c-filt.c code, which served as the precursor for vile's current syntax coloring implementation.
The initial changes to create vile from micro-Emacs were all done by Paul Fox (pgf@foxharp.boston.ma.us). (By the way, he is not the Paul D. Fox that wrote the Crisp editor.)
– Paul Fox
vile's homepage is
https://invisible-island.net/vile/
Up-to-date copies of vile, including executables for DOS,
Win32 and OS/2 are found at
There are also links on vile's homepage, for the most often used executables and sources.
Development patches are found at
In addition, we have distributed copies at other sites, including metalabs.unc.edu (Linux), hobbes.nmsu.edu (OS/2) and the VMS Freeware CDROM's.
Submit bug reports via the project mailing list, or via the
web-based bug reporting system. Both of these are available
here:
https://savannah.nongnu.org/projects/vile
Subscribing to the mailing list is also the best way to keep informed of new releases.
This information is also available online:
https://invisible-island.net/vile/vile-toc.html (table of contents)
https://invisible-island.net/vile/vile-hlp.html (this file)
Copyright © 1995-2021,2022 by Paul Fox, Thomas Dickey, and Kevin Buettner