Getting along with vile (version 9.5) ----------------------- ------------- 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: :q :quit :exit :wq (writes current buffer before quitting) :q! (quits without writing any changes!) Q :wwq or ZZ (will write all changed buffers) ^X-^C (don't know why. _They_ don't put in ":q" for _us_! Actually, if ^C is your interrupt character, this won't get you out of vile.) 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. 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. General Remarks --------------- 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. Command Prefixes ---------------- 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.) Buffer manipulation commands ---------------------------- 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"). _ Show a list of the first 9 buffers. Follow this command with a digit to select that buffer, or simply repeat it ("__") to select the buffer most-recently visited. In autobuffer mode, this is identical to "_1". If autobuffer mode is off, the buffer which will be visited with "__" is flagged with a '#' character in the list. Modified buffers are preceded by a '*' in the history list. There are many different ways to get the previous file: __ _1 (autobuffer mode on) 1_ ( " " ) :e# ^^ (ctrl-^) (but many keyboards can't produce this) 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 '_'.] :e Edit a file. If the file is already in a buffer, that buffer will be recalled into the current window. This occurs as follows: If the name given contains no path delimiters (i.e. slashes), then it will be compared to the existing vile buffer names. Failing that comparison (or if there are any slashes in the name), the name will be stretched into an absolute path, and will be compared to the existing buffers' filenames. In either case, the matching buffer will be chosen. If there are no such matches, the file will be fetched from the filesystem. This matching technique introduces an ambiguity, since buffer names are created from the last path component of filenames. To force vile to edit a file from the current directory whose basename matches that of one that was edited elsewhere, simply preface the name with "./". For example, if you edit "../Makefile" and later attempt to edit "Makefile", vile will assume you are referring to the _buffer_ named "Makefile". To get the file in the current directory, specify "./Makefile". :e! Re-edit a file. A different filename can be given, and the buffer name will change to match it. This command is not as necessary in vile as it is in vi, since multiple buffers may have outstanding unwritten changes. ^X-_ Identical to '_', except that the selected buffer is placed in the current window (windows are described in the next help topic). This is most useful when: - two windows show a different view of the same buffer (for illustration's sake, call the views "A" and "B"). - :e is used to open a new buffer (call this view "C"), which obscures "A". - eventually, you decide to return to "A" and "B". ^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". :n Go to the next buffer. "Next" means "least recently used" in autobuffer mode. In noautobuffer mode, "next" means next in numeric sequence. (The ":n file ..." version of the command is not supported.) :rename-buffer Rename the current buffer. Prompts for a new name. Does not affect the filename associated with the buffer. Use ":f" to do that. This command is useful for renaming the "[Output]" buffer, if you wish to preserve its contents, but run a new command. :set-window Set the current window to the specified buffer. This is useful especially when you have split the screen into a number of windows and want to override the automatic layout of "#" and "%" buffers. :rewind Go to the first buffer. This is used only in 'noautobuffer' (vi-style buffering) mode. It does nothing in "autobuffer" mode. Remember that "autobuffer" mode is the default. :unmark-buffer Clears the "modified" status of a buffer. Useful for the creation of temporary buffer(s) that are discarded when the editor exits. :b Edit a buffer. Recalls the named buffer. Does not look for a file of that name. Will find "invisible" buffers. :ki Kill a buffer. Remove the buffer and its contents from the editor. Will ask if changes to the buffer should be discarded. Multiple buffer names may be specified via wildcards (e.g., :ki *.log) and individual buffer names may be selected via name completion (using the same conventions as in filename completion, described below). ^X-e Edit the file whose pathname appears under the cursor. For example, if you are editing a makefile, you could edit one of the source files by placing the cursor at the start of its name and using this command. Note that this does not know about some characters that your shell might usually translate for you, like the '$' in '$HOME'. ^X-k Kill the buffer whose name or filename appears under the cursor. * Display a list of all buffers, or make that display go away if it's already present. Leave your finger on the key, and it's easy to create and destroy the list. The buffers are numbered; the numbers correspond to the history numbers shown and used by the '_' command, described above. (If the buffer number is greater than 9, then the "nn_" form of the '_' command must be used, since '_' will only accept a single following digit.) The order of the list is either most-recently-used, or fixed, depending on the setting of "autobuffer" mode (see below). vile attempts to keep the contents of the buffer list window up to date if it is left up on the screen while other buffer manipulation commands are given. ^A-* Always display a list of all buffers. Useful for updating the list if it's already on the screen but may be out of date. Any argument will cause the list to include _all_ buffers, even those normally considered "invisible". (For example, macros are stored in "invisible" buffers.) [This command isn't as necessary now that the buffer list is maintained dynamically...] Window manipulation commands ---------------------------- ^X-2 Make Two windows. Splits the current window in half. This is the usual way to create a new window. ^K or ^X-0 Get rid of (Kill) this window. ^O or ^X-1 Make this the Only window on the screen. ^X-o Move to the next window. ^X-O Move to the previous window. v Make the current window smaller. V Make the current window larger. ^A-^D Scroll the next window down half a screen. ^A-^U Scroll the next window up half a screen. ^A-^E Scroll the next window up one line. ^A-^Y Scroll the next window down one line. (The previous four commands are useful when comparing two buffers. Mnemonic -- think of them as affecting the "A"lternate window.) zH zM zL zt zm zb These are synonyms for vi's 'z+', 'z.', and 'z-', which position the line holding the cursor at the top, middle, or bottom of the screen, respectively. (Any of the second characters can be upper or lower case.) Mnemonically, these correspond to the H, M, and L screen positioning commands, or to "top", "middle", or "bottom" -- take your choice. In a macro, only the first character of the argument is significant, but something like "position-window middle" is most readable. Supplying a count will offset that far from the top or bottom of window. (But the middle is always the middle.) ^X-^R Scroll the window right or left by 1/3 of a screen, or by the ^X-^L number of columns specified. Changes the "sideways" value. Neither of these commands will actually move the cursor in the buffer -- they only reframe your view into the buffer. If the cursor would be forced to move off-screen (which is of course impossible and undesirable) as a result of the requested sideways scroll, then nothing at all will happen. The commands are arguably crippled as is. 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.) ] File manipulation commands: --------------------------- 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. 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: ^R Prompts for a filename, and then reads it in _above_ the current line. If a register is specified (e.g., "a^R ), the file is read into that named register, but not inserted into the current buffer. ^W is a writing operator, which prompts for a filename, and writes the specified region to that file. Like all operators, if the command is repeated, as in ^W^W, then lines are affected. Use 10^W^W to write 10 lines. 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. Shell Access ------------ 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 commands 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". Text manipulation command: -------------------------- 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 l (list), p (print), < (left shift), > (right shift), r (read file), d (delete), L (lower case), U (upper case), ~ (flip case), put (append yanked text), Put (prepend yanked text), s (substitute), trim (trim trailing whitespace). 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". Infinite Undo -------------- 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.) (BTW, 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. Operators --------- 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: ^A-~ Is the operator form of the '~' command, so "^A-~~" changes the case of all characters on the current line, "^A-~w" does it to a word, "3^A-~}" does it for 3 paragraphs, etc. (In vile, the simple '~' command will take a repeat count, unlike some versions of vi. If you wish it to be an operator, rebind '~' to the "flip-til" command.) ^A-u Like ^A-~, but converts the region to upper case. ^A-l Like ^A-~, but converts the region to lower case. ^A-f Format the region based on the current fill column. The initial indentation of both the first and second lines of each "paragraph" in the region are preserved, and all subsequent lines get the second line's indentation. This makes indented/outdented paragraphs (like this one) work correctly. (This is intentionally _not_ the same behavior obtained by using "!fmt", since that behavior is obviously available elsewhere.) The usual usage of this command is "^A-f}", which reformats the current paragraph. The re-formatting begins again with each new paragraph, where a paragraph has the same boundaries used by the '{' and '}' commands -- i.e. blank lines, or lines beginning in .I .L .P .Q or .b. This makes it possible to use "3^A-f}" or "^A-fG" to reformat multiple paragraphs. The reformatting operation knows a little about both C, C++, and shell comments, and will attempt to do the "right" thing with lines that start with '#' or '*' characters. (It also knows about the '>' character, making it fairly easy to reformat mail and news inclusions... but is it ethical? :-) ^X-s For every occurrence of a search string, put in a replace- ment string. This is similar to "s/pattern/replacement/g" over the region. ^A-& Is an operator in vile, similar to the traditional & command. It repeats the last substitution over the specified region. (Unlike the '&' command, this one will remember trailing g, p, l, or numeric options.) ^X-d Delete the region, including the lines it starts and ends on. ^X-c Change the region, including the lines it starts and ends on. ^X-y Yank the region, including the lines it starts and ends on. ^A-t Trim trailing whitespace from all lines in the region. ^A- Convert tabs to spaces, using the current tabstop value. ^A- Convert as many spaces to tabs as appropriate. ^A-b Blank out a region. Turns the region to whitespace. Useful with rectangular regions. ^A-r Open up a rectangle. Text to the right of the left edge of the rectangular region will shift to the right by the width of the rectangle, leaving a whitespace "hole". ^A-q Sweep out a rectangle with multiple motion commands. See description of 'q', below. ^A-s Select and yank a region. The region will be highlighted on the screen, as if it had been swept by a mouse. It is also yanked, as with the 'y' operator. This operator is useful in combination with the ^S motion command, which lets one reference the selected region with other operators. (If you use this command much, it is recommended that you bind it to and easier to type sequence, such as 'S'.) See also the q (quoted motion) command. Text insertion -------------- ^X-p Causes the previously yanked or deleted text, no matter how it was obtained, to be inserted after the current line. Usually text that did not consist of whole lines where it came from is inserted immediately following the cursor. ^X-P As above, but the text is put before the current line. Thus "dw" followed by a "p" command does a normal insertion of the deleted word, whereas "^X-p" results in the word being inserted on a line by itself. R vi's overwrite mode is supported. Note that the combination of overwrite mode and the (ANSI) arrow keys can be used to give a "picture drawing" mode of operation: anything you type goes into the buffer without moving adjacent text, and you can move around using the arrow keys without leaving overwrite mode. Hint: start with a buffer full of lines that consist entirely of blanks (as opposed to blank lines). ^A-i Like their 'i', 'o', and 'O' counterparts, but any autoindent ^A-o or cmode setting is ignored for the duration of this insert. ^A-O These are most useful when pre-formatted text is being pasted, as when using a mouse. Searching --------- ^X-/ Does a forward search for the "word" located under the cursor. ^X-? Does a reverse search for the "word" located under the cursor. ^A-/ Does not do a search, but sets the search pattern to the "word" under the cursor. Useful for "picking up" a word from one buffer, and searching for it in another. The following two commands may not always be present in vile, depending on how it was built: ^X-S Incremental forward searching. As you enter the search string, the cursor is advanced to the next match with what you've typed so far. Use ^F and ^R to continue the search forward or in reverse, using the current pattern. ^X-R As above, but in reverse. Tags ---- vile supports vi-style "tags" files. ":ta" or ":tag" allows you to enter a tagname to locate. The editor opens a buffer containing the requested tag. Take note that tag completion is supported, so it's possible to type a partial tagname and then press TAB to force vile to complete the name, assuming it's unique. If not unique, press TAB twice to see a list of all possible completions. Example (using the vile sources): :ta is_sl 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. ^] Uses the identifier currently under the cursor as the tagname. ^T or ^X-^] or ":pop" - pops to the file and location just previous to the last tag command. ^A-^] or ":next-tag" continues searching through the tags file(s) for additional matches. 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". Miscellaneous commands ---------------------- ^A-d Remove blank lines ("deblank"). If the cursor is on a blank line, then it and any blank lines surrounding it will be removed. If a non-blank line, then any immediately following blank lines will be removed. If given an argument, will force exactly that many blank lines to exist at that point, regardless of how many were there before. Moves current location forward, to allow repeated use. ^X-^X The "error finder". Goes to the next file/line error pair specified in the last buffer captured from a command's output. This buffer is usually created with the ^X-! command. 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]\+\):\(.\+\) ; 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]. ^X-t Set or report on the tab-stop width. To set, the spacing must precede the command, as in "4^X-t". The "set tabstop" command described below does the same thing. The status output indicates whether the buffer is currently using the local or global copy of the tabstop value. ^X-f Set the local fill-column to be used with ^A-f and auto-wrap mode on insert. The default value is 7/8's of the screen size, with a maximum of 70. Since arguments come before commands, you type: 65^X-f. The "set fillcol" command does the same thing. The status output indicates whether the buffer is currently using the local or global copy of the tabstop value. ^X-X Set current encryption key for this buffer. See "Encryption" below for more information. K Count prefix. The first time you type it, it is equivalent to an argument of 4 to the following command. If you repeat it, it becomes worth 16, the next time 64, etc... % In addition to finding matching braces, brackets, and parentheses, the '%' command will find matching #if's, #ifdef's and C-style comments. If the cursor is on the # of "#ifdef"/"#if", the '%' command will find the matching "#endif" or "#else". On an "#else" it will find "#endif", and on "#endif" it will go back up to the "#ifdef"/"#if". If the cursor is on any part of a "/*" or "*/" sequence, it will find the appropriate corresponding C comment endpoint. (See fence-if, fence-pairs to customize this behavior). \ Identical to the ` motion, in that the cursor moves to the specified mark (i.e. \a moves to mark 'a'). When used with an operator command, the resulting region is rectangular instead of "exact". This is similar to the ' motion, which also goes to [the line holding] the mark, and causes regions to become "full line" regions. q A "quoted motion" command. After entering 'q', more motion commands are accepted until another 'q' is entered. The result of the motion is the cumulative effect of all the entered motions. Thus, one might type: dq...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. ^A-q As above, but the motions will sweep out rectangular regions. ^S A motion, or "pseudo-motion" command. If a region of text has been previously selected, either with the mouse (if available) or with the keyboard selection operator (^A-s) it can be referenced by any other operator by applying that operator to the ^S motion. As an example, suppose a word is selected with the mouse, or with ^A-sw. Then, from anywhere in that buffer, one can use d^S to delete that word. ^S used by itself will move the cursor to the start of the selected region. ^S applied to the selection operator (^A-s) will extend the current selection to include the current location of the cursor. ^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. = If "visual-matches" is set, then vile will highlight all occurrences of a pattern that is searched for with one of the usual searching commands. The '=' command will clear this highlighting, until the next search for a different pattern. select-all On hosts where vile provides mouse support, the select-all command selects, highlights, and yanks all text in the current buffer to the unnamed register. Clear the selection's highlight attributes as follows: 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: show-abbreviations -- displays list of shortcuts defined with the ":abbr" command. (synonymous with ":abbr") show-buffers -- displays the current list of available buffers. Given any numeric argument, will list _all_ buffers, even those normally invisible or considered temporary. show-color-schemes -- displays a color chart of the user-definable color schemes (see palettes.rc for examples) show-colors -- displays a color chart of the builtin color names, the internal coding used in the syntax filters (e.g., C0), the $palette mapping and examples in bold, italic, etc. show-commands or show-bindings -- displays the list of commands and the keys bound to them. show-global-modes, show-modes -- both synonymous with ":set" show-help -- synonymous with ":help", '^A-h', etc. show-history -- displays the user's command line history. show-majormodes -- displays the builtin and user-defined major modes. show-mapped-chars -- displays the strings mapped for command mode with ":map". (synonymous with ":map") show-mapped!-chars -- displays the strings mapped for insert mode with ":map!". (synonymous with ":map!") show-printable -- displays a table of the printable characters, with associated types. To allow it to fit within 80 columns, abbreviations are used, which are the same names as used in character classes. show-registers -- displays the current contents of the named and numbered registers. show-system-mapped-chars -- displays the strings mapped to represent the terminal's function keys. show-tagstack -- displays the contents of the "tags stack", the list of locations from which the ":ta" or '^]' commands have been used, and to which the ":pop" and '^T' (or '^X-^]') commands will return. show-terminal-chars -- displays the list of special chars normally associated with the TTY driver, i.e. backspace, interrupt, suspend, etc. show-variables -- displays the list of vile state $variables and temporary %variables, and their values. New Registers ------------- 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. Completion ---------- 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. Arrow keys ---------- 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. Rectangular regions ------------------- 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: ^A-r Opens up a rectangle. Text to the right of the left edge of the rectangle is shifted right by the width of the rectangle. > Shift right. Identical to '^A-r' when region is rectangular. d Deletes the (rectangular) region. Text to the right moves left to fill the rectangle. < Shift left. Identical to 'd' when region is rectangular. y Yanks the (rectangular) region. (vile remembers that the yanked text is rectangular in shape. c Change the region. If the region is _not_ rectangular, insert mode is entered after the region is deleted. If the region _is_ rectangular, the user is prompted for text with which the lines of the rectangle will be filled. ^A-u ^A-l ^A-~ ^A-b These four operators perform their character transformations on rectangular regions, as well as exact or full-line regions. (uppercase, lowercase, flip-case, and blank, respectively) p P The 'put'ting commands know whether the text being 'put' was originally rectangular, and will do a rectangular insert of the text, in front of or behind the cursor. The cursor position defines the upper left corner of the insertion. ^A-p These two forms of the put command force the text being ^A-P 'put' to be inserted as if it had been rectangular when originally yanked or deleted. The width of the rectangle is the length of the longest line in register being 'put'. 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. ] Editor modes ------------ 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: 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" Flavor: universal modes ----------------------- 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 unset setno 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. Flavor: buffer 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. Flavor: window modes -------------------- 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. Flavor: majormodes (later) -------------------------- 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". Current mode settings --------------------- To display modes, use "setall", "modes", or "set all". Local mode values are only shown if they differ from the global values, whether they have been independently set or not. Modes in detail --------------- 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. alt-tabpos (atp) If set, vile will position the cursor over tab and control characters the way emacs would, that is, at the start of a tab or control character display sequence. If turned off (the default), the cursor is positioned over tabs and control characters the way it would be in vi, i.e. at the end of the tab or control character display sequence. (To match the behavior of earlier versions of vile, should be set.) (U) animated Controls whether vile automatically updates the contents of scratch buffers when their contents would change. The animated buffers include: [Binding List] [Buffer List] [Color Palette] [Color Schemes] [Command-Bindings] [Error Expressions] [Error Patterns] [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) autobuffer (ab) Controls whether vile uses "most-recently-used" style buffering, or vi-style (command-line order) buffers. That is, if autobuffer is on, then buffers are sorted in order of use, in that buffers not frequently used will drift to the end of the list. If this mode is not on, then vile will behave more like vi, in that buffers remain in a fixed order, that in which they were edited. (U) autocolor (ac) Automatic syntax coloring. If set to zero, automatic syntax coloring is disabled. Otherwise, it should be set to a small positive integer which represents the number of milliseconds to wait before invoking the "autocolor-hook" hook. The editor will wait the specified amount of time for a "quiet interval" during which the user hasn't pressed any keys. (B) autowrite (aw) vile will write out any changed buffers for which this mode is set before performing a ^Z, "stop", "suspend", ":!", or '^X-!'. The ":sh" command is not affected, nor is ":stop!" or ":suspend!". Since buffers inherit the global value of a mode, simply setting the global autowrite value will cause all buffers to be auto-written. Individual buffers can be forced or prevented from autowriting by setting the local value of the mode for those buffers appropriately. [In real vi, autowrite mode will also force buffers to be written when switching between files. This is unnecessary in vile.] (B) autoindent (ai) During insert, newly created lines inherit their leading indent from the previous line in the buffer. (B) autosave (as) Automatic file saving. Writes the file after every 'autosavecnt' characters of inserted text. Other file changes are not counted. (B) autosavecnt (ascnt) How often (after how many inserted characters) will automatic saves take place. 256 by default. (B) backspacelimit (bl) When in insert mode, this controls whether one can backspace past the point at which the insert began. (B) backup-style Specifies the style used for creating file backups when a file is written. Can have values of "off", ".bak", and (under UNIX) "tilde", for no backups, DOS-style .BAK files, and file.c~ style backups, respectively. Files are copied before being written, to protect links to the original file. Permissions, modification and access times are all preserved. If creation of the backup fails, the write of the file will fail, unless it is forced using the ":w!" form of the write command. (U) bcolor On systems supporting this, will set the background color. On most systems, the choice of colors is fixed, although the X11 version (xvile) can be given customized colors at startup or via .Xdefaults. See notes about the color palette down below, under DOS specifics. (U) ccolor On systems supporting this, will set the cursor color. On most systems, the choice of colors is fixed, although the X11 version (xvile) can be given customized colors at startup or via .Xdefaults. See notes about the color palette down below, under DOS specifics. (U) check-modtime Check modification-time. If a file has changed since it was last read or written, vile will issue a "file newer than buffer" warning and prompt appropriately for confirmation when 1) popping up a window on an existing buffer, 2) reading or writing the buffer, or 3) after performing some shell command. 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) cindent (ci) C-style indentation. Helps maintain current indentation level automatically during insert, like autoindent, above. See cindent-chars for additional information. Note that when the majormode cmode is in effect, cindent assumes a local buffer mode value of true. (B) cindent-chars (cic) The list of characters interpreted by the cindent mode. These include '#' when a line starting with '#' is inserted, it is indented to column 1. This is a temporary indent; succeeding lines are indented normally. Also, lines beginning with a '#' will not shift right with the '>>' command. ':' indent the next line further, e.g., after a label. 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) cmode C-code mode. A built-in majormode that predefines cindent mode and separate suffix, tab and shiftwidth submodes. The topic "cmode: the original vile builtin majormode" discusses this majormode in more detail. (M) crypt Causes buffer(s) to be decrypted when read, and encrypted when written. This is compatible with the UNIX crypt(1) routines used by vi, and is only available on platforms which have this feature enabled. See the section on "Encryption" for more information. (B) color-scheme (cs) An aggregate of fcolor, bcolor, video-attrs and $palette. Color schemes are defined with the define-color-scheme command. (U) comment-prefix A regular expression denoting the portion of a line that is replicated and untouched, except for leading indentation when doing text formatting. The expression should begin with "^", e.g., the default value ^\s*\(\s*\([#*>]\)\|\(///*\)\)\+ is useful for matching shell comments (#), multi-line C comments (*), multi-line C++ comments (//), and email (>). (B) comments A regular expression defining commented paragraph delimiters. This is used in addition to the "paragraphs" expression (see below) when reformatting a region. The net effect is that paragraphs inside of these comments are preserved when doing text reformatting, but are not reachable with the '}' and '{' motions. A pattern that consists of an empty comment line usually works well. (B) dirc Causes vile to check each name when scanning directories for filename completion. This is slower, but provides additional information allowing you to distinguish between directory and file names in the prompt. (U) dos On input, if the global copy of this mode is set, then incoming CR/LF pairs are taken as line terminators, the CR characters are stripped out, and the local dos mode is set for the buffer. (Actually, the local dos mode is only set if the _majority_ of lines had CR characters at the end.) If global dos mode is _not_ set, then incoming CR characters will be left visible on the screen (as '^M'), and the local mode will not be set. 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. 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) errorbells (eb) Controls whether a bell sounds (or whether the screen flashes, if "flash" mode is on) when an error occurs. (U) expand-chars Controls the set of characters that are expanded in command lines. These include '%' (the current buffer), '#' (the alternate buffer), '!' (the last shell command) and ':' (the token at the cursor position). For VMS, MS-DOS, OS/2, and Win32 hosts, this is '&'. (U) expand-path Controls whether %/# are expanded to the full pathname of a buffer, or just to its basename (i.e. the name with the path stripped off). (U) fcolor On systems supporting this, will set the foreground color. On most systems, the choice of colors is fixed, although the X11 version (xvile) can be given customized colors at startup or via .Xdefaults. See notes about the color palette down below, under DOS specifics. (U) fence-begin fence-end Respectively, the regular expressions for balancing simple (character-oriented, non-nestable) fences. (B) fence-if fence-elif fence-else fence-fi Respectively, the regular expressions for balancing line-oriented, nested fences, e.g., as C-preprocessor lines (the default). (B) fence-limit Iteration timeout for complex fences, to limit pathological cases, e.g., with Perl's ambiguous block syntax. (B) fence-pairs (fences) Each pair of characters in this string is taken to be a set of "fences", which should be matched with the '%' command. The default value is "{}()[]", which produces normal vi behavior. This can, for instance, be augmented with the '<' and '>' characters ("{}()[]<>") to cause angle brackets to be matched as well. See "showmatch" mode for another use of the "fence-pairs" mode. (B) fillcol (fc) Sets the value for the fill column, which is the column at which autowrapping and region formatting will break lines. If zero, use the wrapmargin. If negative, count from the right margin. (B) filtermsgs (fm) A few syntax errors are detected and highlighted by the syntax-highlighting filters. If set, this mode directs vile to write into the [Filter Messages] buffer the associated error messages, which can be used with the error-buffer command to step through the errors. (B) filtername (fn) Specify a syntax-highlighting filter, for a given majormode. This is used in the filters.rc file, to handle special cases where different sets of keywords are applicable to a common syntax, e.g., C, C++ and Java. End users will not typically modify this mode. (B) find-cfg Configures the builtin find feature, which is available on win32 and Unix hosts. For further details, refer to the section of this help file entitled "Working in a project hierarchy". (U) flash If your terminal can, will flash the screen rather than beeping on errors. No audible or visible indication will occur at all if "errorbells" mode is not set on. See also the vtflash mode (described below). (U) for-buffers (fb) specifies whether globbing or regular expressions are used to select buffer names in the for-buffers and kill-buffer commands. (U) The choices are mixed globbing with special exclusion for internal names, i.e., with square brackets glob the same as filename globbing regex regular expressions glob Controls how wildcard characters (e.g., '*' and '?') are treated in prompts for filenames. Set glob to 'off' to disable expansion, or to 'on' to use the internal globber. The internal globber will handle *, ?, [a-z] style ranges, environment variables, and the ~user notation for finding home directories. 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). highlight (hl) When false, syntax highlighting is disabled in the corresponding buffers. This allows you to disable highlighting for all buffers or only certain ones. (B) history (hi) When true (the default), commands from the :-line are logged in a buffer [History]. Turning this off causes the buffer to be removed. (U) horizscroll (hs) If the cursor is moved "off-screen", this mode controls what happens. If set (as it is by default), the whole screen will shift sideways to make the cursor position visible. If not set, then only the current line will shift, which may be desirable on slower displays. (W) ignorecase (ic) Text searches normally match the pattern exactly. With this set, searches are case-insensitive. (B) ignoresuffix (is) Strip the given pattern from a filename before matching it for majormode suffixes. Note well the difference between the mode's name and its behavior. (B) implybuffer (ib) Causes vile to create a buffer when you write to a new file, or read from one (e.g., with ":r"). (U) insert-exec (ie) Tells vile to interpret control characters for movement and undo/redo if they are bound to appropriate functions during insert mode. For example, ^F and ^B would scroll forward and backward. ^A and ^X bindings are honored as well. (U) linewrap (lw) Displays lines that are too long to fit on one line as a series of "wrapped" lines. Overrides left/right scrolling controlled by "sideways" and "horizscroll" modes. (W) list (li) The buffer will be displayed with tabs and newlines made visible, instead of as whitespace. (W) loading A flag whose state may display in the mode/status line, used by the capture.pl script to show when asynchronous data is loading. (B) magic Honor unescaped regular expression metacharacters in search strings. See the section "Regular Expressions" for more detail. (B) mcolor Specify the color of the modelines, normally in reverse video. (U) meta-insert-bindings (mib) Controls behavior of 8-bit characters during insert. Normally, key-bindings are only operational when in command mode: when in insert mode, all characters are self-inserting. If this mode is on, and a meta-character (i.e. a character with the 8th bit set) is typed which is bound to a function, then that function binding will be honored and executed from within insert mode. Any unbound meta-characters will remain self-inserting. (B) mini-hilite (mh) When user toggles editing mode in the minibuffer (^G, mini-edit), display the minibuffer with the given attribute. These are the same as for visual-matches. (U) mode-filename (mf) A regular expression describing filenames for which the corresponding majormode will be set. The expression is applied only to the portion of the complete pathname after removing the directory name. (M) mode-pathname (mp) A regular expression describing pathnames for which the corresponding majormode will be set. (M) mouse for OS/2, enable/disable the mouse in the console-window version. multibeep If a motion command fails, then vile, like vi, will normally sound the bell. Turning this mode off prevents subsequent identical motion failures from also sounding the bell. That is, if you repeat a failed motion many times (e.g. by holding down the backspace key), you only get one beep. (U) newline (nl) The buffer ends with a newline. This is set when reading a buffer. (B) number (nu) All lines in the buffer will be prefixed by their line number. (W) maplength Controls the maximum length of a :map string, to prevent runaway recursion. This is the total number of characters that can be gotten during a :map expansion; vile pushes characters onto the stack, so this is only a rough measure. (U) maplonger Controls whether the longer or shorter of two "nested" map strings will be favored by the editor. When set, vile will match the longest available mapped string. When reset, (the default) vile will match the shortest available map. For more information, see the section describing the ":map" command, below. (U) overlap-matches Modifies the highlighting shown by visual-matches to control whether overlapping matches are shown. For some conditions, setting this to false will present a more natural view, e.g., "\a+", which would match sequences of alphabetic characters. In the normal case (show overlap), each time a new match begins vile will toggle the highlighting and produce an irregular effect. (B) paragraphs A regular expression defining where the "next-paragraph" ('}') and "previous-paragraph" ('{') commands will go. (B) percent-crlf Percentage of total lines which must end with CR/LF for vile to automatically convert buffer's recordseparator to crlf. (B) pin-tagstack If set, the editor does not change windows when executing tag locate/pop commands. Put another way, all tag push and pop operations are "pinned" to the current window. (U) popup-choices (pc) Must be set to one of the following three values: "off", "immediate", or "delayed". 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) popup-msgs (pm) When enabled, vile pops up the [Messages] buffer showing the text that was written to the message line. Closing the window clears its content until the next message is written. This is most useful during the debugging of macros, since many messages may appear, each overwriting a previous one. This mode is treated specially during startup; unless the startup file (e.g., .vilerc) sets it, all messages will be popped up, then the mode will be initialized to "false". (U) preamble (pre) A regular expression describing the first line of filenames for which the corresponding majormode will be set. For example, you may have a majormode "sh", with sh-preamble set to "^#\s*!\s*\/.*sh\>" to match the lines "# ! /bin/sh", "#!/bin/csh -f", etc. (M) printing-low The integer value representing the first of the printable set of "high bit" (i.e. 8-bit) characters. Defaults to 0. Most foreign (relative to me!) users would set this to 160, the first printable character in the upper range of the ISO 8859/1 character set. Characters 128-159 are control characters in the ISO scheme (e.g., ISO 8859-1). (U) printing-high The integer value representing the last character of the printable set of "high bit" (i.e. 8-bit) characters. Defaults to 0. Set this to 255 for ISO 8859/1 compatibility. The printing-low and printing-high modes are not necessary if your system supports the locale functions. (U) reader-policy (rp) Control whether buffers are initially read using the fast and/or slow methods. The fast method uses less memory, but in cases where there is little free memory, or the heap is fragmented, the slow method may work. However, the slow method is much slower. This mode defaults to "both", which means that the quick method is tried first, and if it fails to allocate the large chunks needed for the buffer, it will retry using the slow (small chunk) method. Set to "fast" to use only the fast method, and to "slow" for only the slow method. (U) readonly (ro) Prevent writing a buffer to its associated file. Unlike "view" mode (see below) which prevents any modifications to a buffer, this mode allows changes, but prevents updates. This is set automatically for the output of shell commands and pipes. (B) readonly-on-readonly (roro) Causes "readonly" mode to be set for read-only files. Normally vile will attempt to write files whether the operating system will allow it or not. This mode should be turned on to truly mimic vi's default behavior. (U) recordseparator (rs) Specify format of files that vile reads and writes. Formats are lf (for Unix), crlf (for DOS), cr (for Macintosh) and default (lf or crlf, depending on the platform). When reading from a file, vile determines the file format automatically, and sets 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) remap Controls whether :map or :map! sequences entered with no explicit remapping control should be subject to remapping (i.e. recursive mapping). (U) remapfirst Controls whether the first character of a map expanded due to :map or :map! is eligible for remapping. This is off by default for vi compatibility. (U) report A threshold value that is used to control messages that report the number of lines deleted, changed, etc. Set it to 0 (zero) to disable the messages. (U) resolve-links Controls whether vile fully resolves file names in cases where some path components are symbolic links. This makes vile smarter about symbolic links that provide multiple paths to a given file, and ensures that files are always represented in vile by their "true" names. (This can prevent multiple unintentional edits of the same physical file via different pathnames -- but see also "unique-buffers", below.) It may trigger long timeouts on systems where symbolic links are used in conjunction with NFS automounted directories. (Note that this does not detect or prevent multiple edits caused by hard file links -- only symbolic ones.) (U) ruler Shows the current line and column in the status line, as well as what percentage of the current buffer's lines lie in front of the cursor. (This percentage is different than that given by ^G (the "position" function), which gives a percentage of characters rather than lines.) (B) samebangs (sb) Controls whether the ":!!" and "^X-!" commands remember the same command string. (U) sections A regular expression defining where the "next-section" (']') and "previous-section" ('[') commands will go. (B) sentences A regular expression defining where the "next-sentence" (')') and "previous-sentence" ('(') commands will go. (B) shiftwidth (sw) This is much like a tabstop, except that it is independent of hardware tabs and tab characters. It is the number of columns a line will shift by if the '<<' or '>>' commands are used, and it chooses the next column stop for the cursor if a '^T' or '^D' is typed during insert mode. Note that when the majormode cmode is enabled, shiftwidth assumes the local buffer mode value of 8. (B) showchar (sc) Controls whether the modeline can show the %C formatted character at the current editing position (W). showformat (sf) Controls when/whether recordseparator information is shown in the status line. Values are "always", "differs" to show when the local mode differs from the global, "local" to show whenever a local mode is set, "foreign" to show when the recordseparator differs from the native default and "never". On Unix, the native recordseparator is a line-feed, on DOS it is carriage-return/line-feed. (B) showmatch (sm) During insert, if a closing "fence" character (usually '}', ']', or ')', but may be changed by setting "fence-pairs") is typed, the cursor will highlight the matching member of the pair for about a quarter second. (B) showmode (smd) Causes an indicator on the modeline to indicate what mode vile is currently in: insert (I), replace (R), or command (none). (B) showram (sr) Displays the amount of ram currently allocated at the end of the message line. (not in all versions) (U) sideways Will prompt for a new value for the sideways scroll offset, which allow display of a section of code normally off the screen to the right. Also affected by the ^X-^R and ^X-^L commands. (W) smoothscroll (ss) Force smooth scrolling. By default, this option is turned off so that vile will try to keep up with your keystrokes instead of keeping the display up to date. Some keyboards repeat faster than the screen can keep up causing the screen to jump. If this bothers you, set smoothscroll to true. Warning: If your keyboard repeats really fast and you have smoothscroll enabled, it may take a while for vile to catch up. (U) spaces-after-sentence (sas) Insert two spaces after each sentence when formatting a paragraph. By default this option is turned on. When disabled, the format routiine will insert only one space after each sentence. (U) suffixes (suf) A regular expression describing filename suffixes for which the corresponding majormode will be set. The expression is applied only to the portion of the filename beginning with the first ".". If more than one of mode-pathname, mode-filename and suffixes are given, they are tested in this order. (M) swap-title For xvile/winvile, if set, the editor displays its title as: - The swapped order is especially useful under limited screen real estate conditions. (U) tabinsert (ti) Allow the physical insertion of tab characters into the buffer. If turned off ("notabinsert"), and an attempt is made to insert a tab character by explicitly typing it or by using shiftwidth or the line shifting commands, then the appropriate number of space characters will be inserted instead. Use '^V^I' to insert a real tab, and remember that pre-existing tabs will not be affected. Use the '^A-' operator command to eliminate pre-existing tabs from a region of text. (B) tabstop (ts) Set the value for spacing of normal tabstops. Note that when the majormode cmode is enabled, tabstop assumes the local buffer mode value of 8. (B) tagignorecase (tc) Causes tag searches to be done ignoring upper and lower case. (B) taglength (tl) Sets the significant length for tags. If non-zero, lookups for names longer than the taglength value will only attempt to match that many characters. If a lookup is for a shorter pattern, or the value of taglength is zero, then the tags must match the lookup pattern exactly. This will not effect tags picked up from the cursor -- they are always matched exactly. (B) tagrelative (tr) Causes files looked up via the tags mechanism to be found relative to the location of the tags file, rather than relative to the current directory. This allows the same tags file to be useful from different locations, while not requiring absolute filenames. For example, using `set tags "tags ../tags"' would allow a single tags file (located in the parent) to be used in a small source hierarchy from either the parent or a child directory. (B) tags Gives a path of names of file(s) in which to look up tag references. It is a whitespace-separated list of filenames. Relative pathnames in this list are evaluated with respect to the current directory of vile at the time of the tags lookup. (B) tagword (tw) When scanning the word to lookup from the cursor position for the tags mechanism, grab the whole word rather than the substring starting at the cursor position. The latter, which is vi-like, is the default. (B) terse vile produces more "status" messages than vi, which may become annoying at low baud rates. Setting terse mode will suppress many of these. (B) terse-selections (tsel) Boolean indicating whether or not additional information is displayed about a selection. When false, the starting and ending positions of the selection are displayed as the selection is extended. The default is true. (W) timeoutlen How long to wait for the characters of a :map'd sequence. Typically needed to resolve the ambiguity between a user-pressed ESCape key and an ESC character that is part of a function key sequence. vile will wait for "timeoutlen" milliseconds after seeing an ESC, in order to check the next character of input. The time defaults to 500, or half a second. Users of fast local screens, like a local xterm, may wish to reduce this to something like 50 for crisper response to a user-pressed ESC. (U) timeoutlen-user If set non-zero, this will enforce a maximum waiting time for characters in a user-defined :map sequence. If zero, the value of timeoutlen, above, will be used for both "system" and user sequences. It is likely that a short time is desired for system sequences, and a long time for user sequences. For this reason the default value of timeoutlen-user is 60000. This will give a full minute to type each character of a user-defined :map. Be careful -- extremely large values may overflow the word size on smaller machines, i.e, you will probably want to avoid setting timeoutlen-user larger than 65535. (U) undo-dos-trim (udt) Controls whether trimming of carriage returns and control/Z done when converting between Unix and DOS line endings is undoable. undoable (ua) Controls whether changes are saved on the undo stack. This is normally enabled, but you may wish to disable it to reduce memory overhead when filtering very large files. (B) undolimit (ul) Sets a limit on how many undoable buffer-changing commands will be saved. If set to 0, there is no limit, and all changes are undoable. The default value is 10. (B) unique-buffers When vile is asked to read a file into a buffer, it will first check to be sure that it doesn't already have a copy of that file, by the same or a different name. This can prevent multiple unintentional edits of a file which appears twice in the filesystem due to hard or soft links. On UNIX systems vile uses the combination of filesystem device and inode to check for uniqueness. vile will represent the file by the first name used to refer to it. Note that unless "check-modtime" is also set, a file with more than one name which is edited and then replaced on disk without the knowledge of the editor may still be edited twice. Setting this mode may be a no-op on non-UNIX systems. (U) unprintable-as-octal (uo) If an 8-bit character is non-printing, it will normally be displayed in hex. This setting will force octal display. Non-printing characters whose 8th bit is not set are always displayed in control character (e.g. '^C') notation. (B) video-attrs Overlay all text with the given attribute: bold, italic, reverse, underline or none. (U) view View the file only. No changes are permitted. (B) view-on-readonly (viewro) Causes "view" mode to be set for read-only files. (U) visual-matches When a search command is executed, the cursor will move as usual. In addition, all matching occurrences of the searched-for pattern (in the current buffer) will be emphasized according to the value of this mode: "none", "underline", "bold", "italic", or "reverse". Additionally, on systems which support color, this mode may be used to set the text foreground color using any of the color values. 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) vtflash If your terminal does not support a visual flash feature, but does support the DECSCNM control sequences that toggle normal/inverse screen video (a feature available with vt100 and later terminals), then a visual bell effect may be achieved using this mode. 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) warn-blanks When prompted for a filename, vile normally allows you to use leading and trailing blanks and other nonprinting characters. Set this mode if you prefer to be prompted. Vile will then prompt you if you want the nonprinting characters to be stripped from the given filename. (U) warn-rename When using ":e" to find a file that has the same name as another buffer, vile will normally offer for you to edit the proposed alternate name for the buffer constructed by adding a "-1", "-2", etc. to the end of the name. Turning off "warn-rename" will make vile choose buffer names without user intervention. (U) warn-reread When using ":e!" to reread a buffer from the file on disk, vile will normally warn you that you are about to clobber a modified buffer. Turning off "warn-reread" mode will make vile assume you known what you are doing. (U) warn-unread When leaving the editor, if not all buffers have been "visited", then normally vile will complain, and remind the user to use ":q!". Turning off "warn-unread" mode will suppress this behavior. (U) working If turned off (noworking), will suppress the activity indicator ("working..."/"...working") which appears during long-running operations. (U) wrapmargin (wm) Implements vi's auto-wrap mode. If nonzero, the wrapmargin specifies the number of columns on the screen's right margin to reserve before breaking the input lines on a preceding space. Thus 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 shouldn't both be used at once. (B) wrapscan (ws) Text searches will continue from past the bottom of the file to the top, and vice-versa. (B) wrapwords (ww) [deprecated] Similar to, but different from, vi's auto-wrap mode (i.e. "wrapmargin"). While inserting, words are moved to the next line if the current line gets too long. Wrapping is only attempted when a space is typed. The target maximum width of lines is changed with the "fillcol" setting. (B) xterm-mouse Enables mouse-clicking if you are running within an xterm. That is, it allows vile to receive mouse events. Since this mode overrides xterm's cut & paste, you will need to use the Shift key when pressing the mouse buttons to cut and paste between X windows. Your TERM variable's termcap entry should contain the string "xterm" for this to work. (U) xterm-title Enables titlebar updates if you are running within an xterm. Each time you switch to a different buffer, vile can update the title. This uses the same tests of the TERM variable as the xterm-mouse mode. (U) yankmotion (ym) Yanking text will cause cursor movement (just like vi) if the motion is left or up. (B) 8-Bit Operation --------------- vile allows input, manipulation, and display of all 256 possible byte-wide characters. (Double-wide characters are not supported.) Output ------ By default, characters with the high bit set (decimal value 128 or greater) will display as hex (or octal; see "non-printing- 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. Input ----- There are basically three ways of getting 8-bit characters into a vile buffer: Directly -- if the user's input device (i.e. the terminal or xterm) can generate all characters, and if the terminal settings are such that these characters pass through unmolested, then vile will happily incorporate them into the user's text, or act on them if they are bound to functions. On an xterm, try "stty cs8 -parenb -istrip". Real serial lines may take more convincing, at both ends, but use that stty command as a starting point. As numbers -- the ^V prefix (or, more correctly, the key bound to the "quote-next-character" function), if followed by up to three digits, will insert a character whose value is that number (no greater than 255) into the buffer. The number may be entered in decimal (^VNNN), octal with a leading '0' (^V0NNN), or hex with a leading 'x' (^VxNN). As digraphs -- Perhaps more useful to some people is using a set of ":map!" commands to aid insertion of 8-bit text. The file "digraphs.rc" distributed with the vile source contains a set of mappings which should aid the input of ISO 8859/1 text. As examples, the mappings in digraphs.rc allow one to type ^KU" or ^Ku" to get an umlaut character, ^K12 to get the little '1/2' symbol, ^KY- to get the Yen currency symbol, or ^K:- to get an arithmetic division symbol. 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 hex 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.) Command History --------------- 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). Editing the Minibuffer ---------------------- 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. Special Character Expansion --------------------------- 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 '\'. Character Classes ----------------- The "show-printable" command shows a table of the characters and their classes, e.g., printable, punctuation, etc. You may modify 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 arg ex-style line range: 1,$ or 13,15 or % etc. ctl control character del delete/backspace fn fence character, e.g., "{" or "}" id normal identifier, used for word boundaries lwr lowercase, e.g., "a" nsp nonspace num digit, e.g., "0" path file/path name prn printable pun punctuation qid qualified identifiers, used in tags parsing sh may appear in shell/pipe sp space tmp legal in scratch-buffer names upr uppercase, e.g., "A" wld shell wildcard, e.g., "*" You can also reset the table to its initial state using "reset-char-classes". Key Rebinding ------------- 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 hex or octal as well, in the form 0xNN, where NN is exactly two hex digits. So if you know the hex 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: default - for commands in screen mode as well as those that do not fit naturally into one of the specialized modes. This is initialized by compiled-in definitions for normal (0-127) and special (function and meta-key) definitions. bind-key describe-bindings describe-key unbind-key cmdmode - for command editing. This is initialized with the special keys from the default table, as well as the control characters that are associated with movement, e.g., ^N and ^P. bind-cmdmode-key describe-cmdmode-key show-cmdmode-bindings unbind-cmdmode-key insmode - for insertion. This is initialized with the special keys from the default table, as well as the control characters that are associated with movement, e.g., ^N and ^P. The insert-exec mode controls whether those control characters are interpreted or inserted. bind-insmode-key describe-insmode-bindings describe-insmode-key unbind-insmode-key selmode - for selection highlighting, i.e., multimotion. This is initially the same as the default binding table, but may be customized. bind-selmode-key describe-selmode-bindings describe-selmode-key unbind-selmode-key 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. Syntax for key-sequences: ------------------------- To summarize, a key-sequence being bound to is specified with: 1) an optional prefix, like this: ^A- (three chars) ^X- (three chars) ^A (one char) ^X (one char) 2) followed by an optional "function" prefix: #- (two chars) or FN- (three chars) 3) followed by an optional "meta" prefix: M- (two chars) (this is the same as with specifying a character in that has the high bit set) 4) followed by a character, like this: 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.) Function Keys ------------- 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". :map, :map!, :noremap, :noremap! --------------------------------- 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 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 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 (hex), \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" (or ":show-mapped-chars") or ":map!" (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". :abbr ------ 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". Special "Terminal" Key Rebinding -------------------------------- 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. 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 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) Flow-control ------------ 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. Recorded macros --------------- 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. ^X-( Begin or end the recording a keyboard macro. The ^X-) keystrokes you type are recorded. For compatibility with previous versions of vile (where separate commands were necessary), these two commands are now both bound to the same function. The start/stop capability is now a toggle, and requires only one command. ^X-& Execute the keyboard macro. ^X-^ Copy recorded keyboard macro to a named register, for saving, or for execution using '@a', as below. (Type "a^X^, where "a means yank into register-a) 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.) Programmed procedures (aka macros) ---------------------------------- [ 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. Numbered macros --------------- The numbered macro syntax looks like so: store-macro ... ~endm A numbered macro is executed using this command: execute-macro- To bind a keystroke to this macro, use this command: bind-key execute-macro- 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. Named macros ------------ A named macro, aka "stored procedure", uses this syntax: store-procedure ... ~endm where: unique-name is an alpha-numeric identifier that does not conflict with the name of any existing editor command (the show-commands command generates a list of all existing commands). A stored procedure is executed by simply referencing its name. To bind a keystroke to this macro, use this command: bind-key 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: + press "#h" within the editor, or + simply use the name "write-msg-tst" as if it were any other built-in editor command. This means that "write-msg-tst" can be invoked from another macro, from a startup/configuration file, or from vile's command line, like so: :write-msg-tst Note that named macros may also include parameters and a help string, each of which are described in doc/macros.doc. Macro Language Elements ----------------------- 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. 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: $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) $bflags status flags for current buffer (read only) a autobuffer caused this to be created d directory listing i invisible, e.g., tags m modified s scratch, will be removed when popped down u unread $blines number of lines in current buffer (read only) $brightness RGB levels for gray, normal, bright in the 0-255 range (winvile version only) $buffer-hook name of procedure to run when switching to a buffer $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). Currently tracked options include: athena -> xvile built with Athena widgets curses -> editor uses curses terminal driver locale -> editor uses system's LC_CTYPE locale motif -> xvile built with Motif libraries nextaw -> xvile built with Athena widgets (NeXtaw) noshell -> shell commands are disabled oleauto -> editor supports OLE automation. openlook -> xvile built with OpenLook libraries perl -> editor includes perl interpreter termcap -> editor reads TERMCAP db for screen info. terminfo -> editor reads TERMINFO db for screen info. xaw -> xvile built with Athena widgets (Xaw) xaw3d -> xvile built with Athena widgets (Xaw3D) $cfilname current file name $char character under the cursor $cmd-count repeat-counter for the current macro (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) $encoding character set associated with locale (read only) $end-of-cmd true if user ended the cmd with $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) $fence-limit iteration limit for complex fences $filename-expr actual pattern for %F in [Error Expressions] $filename-ic ignore case in filename completion (read only) $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 $helpfile $VILE_HELP_FILE env var or "vile.hlp" (read/write) $iconname current icon name (X11 version only) $identifier current punctuated word $kbd-macro the keyboard macro, see ^X-( ^X-) (read only) $kill some of the kill register (read only) $lastkey last keyboard char struck $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) $majormode current majormode, if any (read only) $majormode-hook procedure to overrride 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". $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 $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 $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) $startup-path where to find the startup file $status returns the status of the last command $title current window title (X11, win32 versions only) $title-format format of window title. see "Mode line customization". $tpause length to pause for paren matching (PC versions) $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" $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. Functions --------- 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. func no. of name args ------------------------ &abs 1 absolute value of a number &add 2 add two numbers together &and 2 logical and &ascii 1 char to integer conversion &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 is a file exec'able &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 &global 1 retrieves global mode setting &greater 2 numeric greater than > 2 numeric greater than >key 0 get 1 character >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 ®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 &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 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). Directives ---------- 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) ~trace cond set $debug trace ~if cond conditional execution ~elseif cond conditional execution ~else ~endif ~return Return (terminating current macro) ~goto label Jump to a label in the current macro ~force Force macro to continue...even if command fails ~hidden Do not update screen while the macro executes. ~quiet Suppress messages while the macro executes. ~while cond Execute a loop if the condition is true ~break ~endwhile ~with tokens prepend tokens to following commands ~endwith stop prepending tokens ~local vars save specified variable(s), restore at end of macro ~endm End a macro 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. Hooks ----- 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-cofigurable 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 overrride 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.) Macro examples -------------- 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 ; explict 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.) Picture Mode ------------ 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": o----------------------------------------o /----------------------------------------/| o----------------------------------------o|| | To use it, first ":source pictmode.rc" ||| | and then "run pic". See the comments ||| | at the top of pictmode.rc for more ||o | information... |/ o----------------------------------------o Regular Expressions ------------------- 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 in the 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 \c string at the end of the input string), a `\' followed by a single c 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 \s \S beginning and end of a "word". Vile recognizes the X/Open regular expression 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. \w \W [:alnum:], alphanumeric (plus '_') \a \A [:alpha:] \b \B [:blank:] \c \C [:cntrl:] \d \D [:digit:] \g \G [:graph:] \l \L [:lower:] \p \P [:print:], printable (note that space is printable) \q \Q [:punct:] \s \S [:space:] \u \U [:upper:] \x \X [: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: ? + ( ) | * [ . < > 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 \1 \9 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. ] The replacement part of the substitution may also contain the \U \L special sequences \U and \L, which cause the replacement to be \E forced to uppercase or lowercase until a terminating \E is found; \u \l \u and \l, which force the case of a single character; and \b, \bfrtn \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. Command files ------------- 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. Invocation ---------- 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/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: VILE_HELP_FILE override the name of the help file, normally "vile.hlp". This sets the $helpfile variable. VILE_LIBDIR_PATH override the search path for filter programs, normally the library-directory on UNIX systems. This sets the $libdir-path variable, which is appended to your $PATH variable when running filter commands on UNIX and Win32. VILE_PWD if set, assume invoking shell's "$PWD" variable is valid, and use that rather than an initial getcwd() call. VILE_STARTUP_FILE override the name of the startup file, normally ".vilerc" (or "vile.rc" for non-UNIX systems). VILE_STARTUP_PATH override the search path for the startup and help files. This sets the $startup-path variable. 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. Command line options -------------------- The command line options are fairly straightforward. vile does not support running just _any_ command after a '+', as does vi, but does 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. Use "vile -?" to get the usage message. +NNN and -gNNN vile will begin the session on the first file at the specified line number. +/pattern or -s pattern In the first file, vile will execute an initial search for the given pattern. -t tag vile will edit the correct file and move the cursor to the location of the tag. This requires a tagsfile created with the ctags(1) command. -h Invokes vile on the helpfile. -v Invokes vile in "view" mode - no changes are permitted to the buffer in this mode. (This will also be true if vile is invoked as view.) -V vile will report its version number. @cmdfile vile will run the specified file as its startup file, and will bypass any normal startup file (i.e. .vilerc) or environment variable (i.e. $VILEINIT). Encryption ---------- 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. Crash Recovery -------------- 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: Unix (in priority order) ------------------------ $TMPDIR/vileDXXXXXX /var/tmp/vileDXXXXX /usr/tmp/vileDXXXXX /tmp/vileDXXXXXX ./vileDXXXXXX DOS and OS/2 ------------ Saved buffers are written to disk using the path ./V . All other hosts (in priority order) ----------------------------------- $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. Mode line customization ----------------------- 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: %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 internal 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. %p line number as percentage of number of lines if "ruler" is set %P line number as percentage of number of lines %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::%-%-:%|" Color basics ------------ 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. Console/standard vile versus GUI vile ------------------------------------- Depending on the host, vile comes in two flavors: + console (or "standard") vile, which displays text with block character, cursor-based addressing. + GUI vile (aka, winvile on a win32 host and xvile on a Unix host), which displays text using the host's GUI APIs. In general, GUI vile supports a richer set of color features and capabilities than console vile. Color palette ------------- 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 Internal User Name 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. xvile custom colors ------------------- 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 custom colors --------------------- 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 Display attributes ------------------ 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). Show-colors command ------------------- The show-colors command (i.e., ":show-colors") displays the editor's current color and attribute mappings. Xterms, terminfo, and termcap (Unix hosts only) ----------------------------------------------- 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: a) your terminal type (specified via the $TERM environment var) supports color, and b) vile is compiled and linked with the terminfo library. Hint 1: On linux hosts, the "xterm" terminal type supports 8 colors (i.e., ensure that "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: http://invisible-island.net/xterm/xterm.faq.html#no_color Visual matching (VM) -------------------- 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= To learn more about this mode, search for "visual-matches" elsewhere in this help file. Foreground color (FC) --------------------- 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= for a list of supported colors. Background color (BC) --------------------- On hosts and display hardware that support it, bcolor mode sets the editor's background color. Bcolor utilizes the same color list as fcolor. Attribute control sequences (ACS) --------------------------------- 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: red text, bold text It's possible to mix colors and attribute as well: ^A8BC1:bold red text which is rendered as: ^A8BC1: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. Syntax coloring (SC) -------------------- vile colors a buffer via these steps: 1) an external filter (e.g., vile-c-filt) is run and subsequently reads an optional keywords file and a color specification file. The latter maps classes of language keywords/elements to user-specified colors and display attributes. 2) the filter reads the buffer being colored from stdin and encodes language keywords/elements with attribute control sequences. 3) the filter writes its results to stdout, which vile reads back and uses as control information to color the buffer. 4) the editor redraws its display, appropriately rendering all attribute-encoded keywords (e.g., "if", "while") and other syntactic elements (e.g., strings and numbers), based on the information embedded in the filter's output. Host capability matrix ---------------------- Color VMS VMS Win32 Win32 Unix Unix Feature (std) (GUI) DOS OS/2 (std) (GUI) (std) (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. Syntax coloring --------------- 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 Builtin External Majormode Name Filter Name Filter Name [1] 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. Prerequisites ------------- a) be familiar with the help topic entitled "Color basics". b) ensure the target host supports syntax coloring. c) if on a Unix host, compile and link the editor from the source distribution. This step is optional on a win32 host, as precompiled binaries (editor and filters) are available from ftp://invisible-island.net/vile/ . Note that almost all filters require preprocessing with flex (not a standard Windows tool) prior to compilation. Configuration ------------- There are three configuration recipes, each dependent on the target host and/or the user's privilege level. Unix install recipe -- root privileges available ------------------------------------------------ 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 directories $HOME/.vile or /usr/local/share/vile as appropriate. Unix install recipe -- no privileges ------------------------------------ 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. Manual Recipe -- Win32 host --------------------------- There is no Win32 install/setup program. Consequently, all Win32 users must resort to manual configuration. 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: ftp://invisible-island.net/vile/filters.zip ftp://invisible-island.net/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. Testing the configuration ------------------------- 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 Attach a major mode to a buffer and re-color same. More about this below. For a simple go/no-go test, do: - edit a C source file - examine the editor's modeline and ensure that "[cmode]" is in effect - type ^X-q 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. Read-hook --------- 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. Autocolor --------- 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. I.E, 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 hardward, 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 Changing color/attribute mappings --------------------------------- 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: - a line that begins with ':' is a comment - language elements are grouped into classes, each of which is assigned a color, using this syntax: .class : where: ::= an arbitrary alphanumeric string. ::= { C | U | I | B | R } C ::= 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. Caution: vile.keywords is a precious file ----------------------------------------- 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! Troubleshooting --------------- Try this checklist when syntax coloring doesn't work: - Does your display hardware and/or host support color? Type ":show-colors" to list current capabilities. If colors/attributes appear to be missing, reread the "Color basics" topic in this help file. - Win32 users should ensure that these environent vars are properly initialized: VILE_STARTUP_PATH VILE_LIBDIR_PATH - Your startup file should include these lines: source "filters.rc" ; quotes matter on win32 hosts setv $autocolor-hook HighlightFilterMsg setv $read-hook HighlightFilterMsg set autocolor=2000 - Some users have made the mistake of explicitly specifying a filter via the filtername mode. Don't do that. Attaching/Forcing a buffer's majormode -------------------------------------- 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 Man pages --------- 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. Spell checking (Unix hosts only) -------------------------------- 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. Further reading --------------- More information on syntax coloring can be found in the file doc/filters.doc, in the vile source directory. Majormodes ---------- 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: 1) the suffix of the file being edited, and 2) the file's preamble (i.e., file's first line). 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 ~with define-submode mode-pathname "" ; see next para mode-filename "" ; see next para suffixes "" ; see next para preamble "" ; see next para before "" filtername "" 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 . 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 ~with define-submode 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 Notes ----- 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 " command. Example: setl cppmode ; <-- force cppmode for current buffer Distinguishing between C/C++ include files ------------------------------------------ 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. cmode: the original vile builtin majormode ------------------------------------------- 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 "" filtername 'vile-c-filt' ~endwith This buitin majormode can produce some surprising results when editing C source files. In particular: set ts= ; <-- 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 Filtering "man" pages --------------------- 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. Working in a project hierarchy ------------------------------ vile includes several features that enable quick access to many files spread over a directory hierarchy, as described below. Directory navigation -------------------- vile provides several commands that manipulate an internal directory stack: :dirs :dirs-add dir :dirs-clear :popd [ {+|-}n ] :pushd [ dir | {+|-}n ] "dirs" lists the directory stack in a scratch buffer. Note that the directory stack is zero-based. Precede this command with an argument to kill the buffer. "dirs-clear" clears the stack and kills the scratch buffer. "dirs-add" adds a directory to stack[top - 1], but does not affect cwd, which makes this command useful for initializing the stack from a macro or startup file. "popd" removes entries from the directory stack. With no arguments, removes the top directory from the stack and performs a cd to the new top directory. +n removes the nth entry counting from stack top. -n removes the nth entry counting from stack bottom. "pushd" adds a directory to the top of the directory stack or rotates the stack, making the new top of the stack the current working directory. pushd honors CDPATH, when set. With no arguments, pushd exchanges the top two directories. Otherwise: +n rotates the stack so that the nth directory, counting from stack top, is at the top. -n rotates the stack so that the nth directory, counting from stack bottom, is at the top. dir adds dir to the directory stack at the top, making it the new current working directory. If pushd or popd is successful, a "dirs" is performed as well. Hierarchical tags ----------------- 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. Exuberant ctags --------------- 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. Standard ctags -------------- 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. File/Directory traversal (win32/Unix hosts only) ------------------------------------------------ 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="[]..." where 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: [][,[,