What is VILE?

VILE - Vi Like Emacs - is a text editor. vile retains the "finger-feel", if you will, of vi, while adding the multiple buffer and multiple window features of emacs and other editors. It is definitely not a vi clone, in that some substantial stuff is missing, and the screen doesn't look quite the same. The things that you tend to type over and over probably work. Things done less frequently, like configuring a startup file, are somewhat (or very, depending on how ambitious you are) different. But what matters most is that one's "muscle memory" does the right thing to the text in front of you, and that is what vile tries to do for vi users.

Who wrote VILE?

A lot of people, of course, as is true of almost all large programs. (No counter examples come to mind for programs larger than vile).

Vile was started by Paul Fox from an early (public domain) version of MicroEmacs. That is a little odd for two reasons:

MicroEmacs is not like the other flavors of Emacs which you may be familiar with, since its extension language is not Lisp. It looks something like Lisp without the parentheses. (Lisp is humorously reported to stand for Lots of Irritating Silly Parentheses).
Vi is supposed to be a "modal" editor, and Emacs not. This is a big issue in the newsgroups, almost as critical as the placement of curly braces in C.

So Paul did a lot of work making vile.

I started working on vile late in 1992. Though I had been using vi for almost ten years, it was with little documentation (I long ago lost a grubby photocopy of vi's commands), and had only recently gotten involved in projects where I would edit large numbers of files. Two buffers weren't enough, and (because I was collecting tools for development) I noticed some discussion of implementations of vi that could handle multiple windows. Vile looked good, but there were a few problems with left/right scrolling (individual lines would shift, but the display did not necessarily shift as a whole). So I started fixing it.

Kevin Buettner came in early in 1994, changing the X Windows driver, and later implementing the Perl interface. Rick Sladkey arrived in 1995, working on win32 and djgpp.

We four are listed as authors of vile - but many more people have contributed code, fixes and feedback.

Vile is not huge - at this time the sources total about 90,000 lines - but is still large compared to some editors. A good deal of the bulk is from I/O drivers for different systems. Most of those drivers were written or modified heavily by other contributors.

What platforms does it run on?

Vile should build properly on any Unix platform (or similar such as Linux, Cygwin and BeOS), using the auto-configure script to check for required system features. The configure script is normally Unix-specific (because it uses a variety of shell commands such as sed), but can be regenerated for some other environments such as OS/2 EMX.

Specialized build scripts and I/O drivers are also provided for non-Unix platforms: VMS, Win32 (console and GUI using Visual C++), DJGPP.

Known/Frequent problems

Building and Installing VILE
- ANSI C compiler is required
- Build for one terminal driver
Configuring VILE
Making Color Work
Finding More Information
- What commands does vile accept?

ANSI C compiler is required

Vile evolved from K&R source, to extended C, i.e., K&R code with ANSI prototypes (which is what many programs are written in). Early in 1996 we chose to convert vile to ANSI C to take advantage of the better type-checking available. So vile requires an ANSI C compiler.

Vile will build with a C++ compiler, though you may have difficulty with the configure script.

Build for one terminal driver

On Unix and Win32, vile can be built for character-cell and GUI terminal types. Most of the terminal-specific I/O calls are made through a generic interface, however you cannot reuse the object files from one type on configuration to build the other.

Some of the Unix configuration tests may yield different results, or be incomplete for one configuration versus another. We remove the config.cache file explicitly in the configure script to circumvent problems with this.

What initialization files are needed?

Vile is similar to vi in some ways, but it reads its own startup file to avoid surprise should you happen to execute vi. Vile's initialization scripts include many commands which would confuse vi.

On Unix, Vile looks for .vilerc, starting in the current directory, then in the home directory, and finally in the installed share-directory (shown in the variable $startup-path).

On other systems (including those that cannot use multiple dots in filenames such as VMS, or do so in a crippled fashion such as Win32), vile looks for vile.rc.

Which initialization files are used?

In either case, you can use the command which-source to show which file is actually loaded. Use a count before the command to show all files which would be checked, and the corresponding matches, e.g.,

	2
	:which-source .vilerc

What environment variables are needed?

The most critical ones are documented in the online help vile.hlp, which you can view by

:h

They include those specific to vile

	VILEINIT
	VILE_HELP_FILE
	VILE_LIBDIR_PATH
	VILE_STARTUP_FILE
	VILE_STARTUP_PATH
	XVILE_MENU (doc/menus.doc)

as well as variables borrowed from common Unix or Win32 convention:

COMSPEC: on OS/2, your shell interpreter.
COLUMNS: the width of your terminal display, for termcap or terminfo configurations.
HOME: your home directory.
HOMEDRIVE: under WinNT, the disk drive containing your home directory.
LINES: the height of your terminal display, for termcap or terminfo configurations.
LOGNAME: used to identify you for reporting errors, or for locking files.
PATH: your execution path, except on VMS.
SHELL: alternative to the $shell variable for specifying subshells, including those used for syntax filtering.
SYS$LOGIN: your home directory on VMS.
TEMP: on Win32 your temporary directory.
TERM: your terminal type, for termcap or terminfo configurations.
TMPDIR: used as the first choice when saving files if a fatal error is detected. Vile uses no temporary files for storing your files' current state otherwise.
USER: alternative to $LOGNAME to identify you for reporting errors, or for locking files.

What can vile color?

Vile makes use of color to make your file easier to read. It has modes to set the foreground, background and status line colors (fcolor, bcolor and mcolor respectively). Add this to your initialization file to get the predefined color schemes:


	source palettes.rc

The most useful schemes are white, black and default, which you can specify by setting the cs mode, e.g.,


	:set cs=white

It can also overlay colors and other visual highlighting on your file to show the syntax. The overlay is computed by an external program, referred to as a syntax filter.

The simplest way to turn on syntax highlighting is to add


	source filters.rc

to your initialization file, e.g., .vilerc. Typing ^X-q will paint colors according to the majormode which applies to the given file. Typing ^X-Q will clear all of the colors.

If you have a reasonably fast computer, adding


	setv $read-hook HighlightFilter

will tell vile to paint colors each time it reads a file.

No colors are shown

Well, you did all that, and there are no colors. If there is a majormode in effect for the buffer, vile attempts to run a syntax filter based on the name of the majormode. Check to see if vile is configured to display colors:


	:show-colors

If that works, then the problem is with the syntax filter (perhaps vile cannot find it for some reason). If it does not work, then you have to set up colors (assuming your terminal can display color).

For character cell terminals on Unix, i.e., termcap or terminfo, vile reads the color information specified by your $TERM variable. See the ncurses FAQ for more information. The X Window configuration, xvile reads the color assignments from resources, and is documented in the online help. The Win32 and other non-Unix ports do not require external files to set up color.

If colors are working, perhaps vile simply did not find the syntax filter.

Where are the syntax filters?

Syntax filters may be built-in, or run as separate programs. The former are more portable, less trouble to run and somewhat faster. The configure script (and the win32 makefile) provide a means to specify that any combination of filters can be built-in or external. Even if they are built-in, vile can still run external filters - that choice is left to the macro which performs the highlighting, e.g., HighlightFilter. You can see which filters are built-in by looking at the result of


		:show-variables

for the $filter-list variable.

Vile looks for external syntax filters in your path - after adding the library directory $libdir-path to the end.

Use


		2:
		which-exec

to display the places where vile looks - an "*" will mark the ones it finds.

It used to work...

We changed the form and use of $HOME/.vile.keywords with version 8.3:

before, that file was used by convention for the C syntax filter, and contained a list of keywords or classes with the markup.
now, it is used for global definitions of class markup, as well as for the vile macro syntax filter.

The old scheme had no provision for multiple syntax filters. The new scheme names keyword files according to the syntax filter which is used, and may load two files, e.g., $HOME/.c.keywords and $HOME/.vile.keywords for C.

To see which files are found, run the corresponding filter with the -v option. For example, vile-html-filt -vv on this file produces output beginning

	ReadKeywords(vile)
	..skip ./.vile.keywords
	Opened /home/tom/.vile.keywords
	parsed	name ""	attr "<null>"
	parsed	name ""	attr "<null>"
	parsed	name "Action"	attr "BC1" - class
	parsed	name "Comment"	attr "C1" - class
	parsed	name "Error"	attr "RC1"
	parsed	name ""	attr "<null>"
	parsed	name "Ident2"	attr "C6" - class
	parsed	name "Keyword"	attr "BC3" - class
	parsed	name "Keyword2"	attr "BC1" - class
	parsed	name "Literal"	attr "C5" - class
	parsed	name "Number"	attr "BC6" - class
	parsed	name "Preproc"	attr "C2" - class
	parsed	name "Type"	attr "BC2" - class
	ReadKeywords(html)
	..skip ./.html.keywords
	..skip /home/tom/.html.keywords
	..skip /home/tom/.vile/html.keywords
	Opened /usr/local/share/vile/html.keywords

The trace notes "..skip" for files that are not found. On Unix, files in the current or home directory are prefixed with "." to hide them. The ".vile.keywords" file is read first, to provide default values for classes.

You can also use the which-keywords macro. For example,

	:which-keywords vile

makes a window showing:

	Show which keyword-files are tested for:
		vilemode
	(* marks found-files)

	$cwd
	  ./.vile.keywords
	$HOME
	* ~/.vile.keywords
	  ~/.vile/vile.keywords
	$startup-path
	* /usr/local/share/vile/vile.keywords

Some words are not colored

The syntax filters distributed with vile do not color every word, but the colors should be consistent, corresponding to the syntax. (Coloring every word detracts from readability; by design most of the text is left with the global foreground color fcolor).

But the coloring may be incomplete or inconsistent, and it may not be due to a coding error in the syntax filter. This may happen when the colors overlaid on your buffer from the syntax filter are not aligned properly. Vile runs the given filter, reads the resulting output and extracts markup from it to paint on your file. If another program produces output, it will confuse vile, since the output is not necessarily aligned with your file.

For example, if your $shell is /bin/csh, and your .cshrc file contains an stty command, that program will write an error message when it is run in a pipe. I work around this by setting $shell to /bin/sh (my .profile is empty), which bypasses messages and is faster:


	setv $shell=/bin/sh

A better solution bypasses the shell entirely. Build vile using the --with-builtin-filters option. That compiles-in the syntax filters, which also runs much faster. The only drawback to that approach is the size of the executable. Your system may also support --with-loadable-filters, which allows you to keep a relatively small vile executable, with some speed advantage over the original external filters.

No words are colored

Well, take this in stages:

Do you have foreground/background color - setting fcolor and bcolor has an effect? If not, then you have to setup color for vile.
Are you running a filter? The filters are all associated with a majormode, whose name shows up in the status line for each buffer, e.g., cmode for "c" majormode. The corresponding filter is named vile-c-filt, and must be installed in a place where vile can find it.
Try running the filter within vile, e.g.,
```
		^X!vile-c-filt -vv %
```
to run the "c" filter into [Output] on the current buffer, in verbose mode. (That's a control/X). The output should show the markup definitions loaded, as well as the marked up file (places with ^A).
- If the filter is not found, perhaps your $shell is resetting $PATH. I work around this by setting $shell to /bin/sh (my .profile is empty), which is faster.
- The ".keywords" files may not be found, perhaps because your buffer's majormode does not match one of those installed.

Flex/lex output does not compile

We recommend building the syntax filters with flex (e.g., version 2.5.4a). You can build workable filters with recent versions of lex, but older ones usually lack the %state support needed for most of the filters.

Some older implementations of lex also assume a different order for the chunks of C code in the lex specification; however these do not appear to work well even when the chunks are moved to make the filter compile.

Chunk-ordering is not solely a problem with antique versions of flex. There is a so-called "new" flex available which introduces similar bugs. While the code can (has been as of 9.4) reordered, the maintainers of this new version do not respond to bug reports (it appears to be a defunct project). Stick with flex 2.5.4a, which works.

What commands does vile accept?

Vile accepts most - not all - commands that vi implements. The few that are not implemented are generally because their syntax is not compatible with vile's command-parsing or name-completion. (For the ones that are compatible - someday).

Vile's extensions over vi are documented in the help file. Detailed descriptions for writing macros, etc., are in the doc directory which is part of the source distribution. But the essential information is in the help file. Just type

:h

The help file is static, and requires you to search it. Far nicer are the features for listing commands, e.g.,

	:describe-bindings

That looks like a lot to type. But it is not. With name-completion, one may press tab to fill in the unambiguous parts and see what choices there are.

	:des<tab>
	:describe-<tab>
	:describe-b<tab>indings
	:describe-bindings

How do I report bugs?

Submit bug reports via the project mailing list, or via the web-based bug reporting system. Both of these are available here:

	https://savannah.nongnu.org/projects/vile

Subscribing to the mailing list is also the best way to keep informed of new releases.

Y2K Compliant?

Certainly.

Vile does not store or retrieve dates in any form that depends on the year. Vile's use of time information is limited to

computing elapsed times, in fractions of a second, and
comparing file creation times, to detect if a file has been modified by another process.

Copyright

Vile is copyrighted by Paul G. Fox, Thomas E. Dickey and Kevin Buettner with some files (e.g., visvile) copyright by Clark Morgan. We distribute it under the terms of the GNU Public License, Version 2.

Contents