In addition, e does spelling corrections on its arguments, fast lookup and editing of files in other directories, and allows for the inheritance of .exrc files in other directories. It also closes the modeline security hole, making it possible to ensure that no .exrc file that you don't own is ever seen by vi.
The vi(1) options -r, -v, -x, -w and -R are all passed as is to vi and so behave as would be expected.
/tmp/mydir
death
+/main.c pete.c
bigmac
fries
"e ." will show you the history...
[3]: death
[2]: +/main pete.c
[1]: bigmac
[0]: fries
"e" by itself will get you immediately back into "fries".
"e -" will present the same as shown for "e .", but will ask for a number or another filename. Carriage return is equivalent to zero (i.e. the last filename), backspace or interrupt will quit.
"e -2" will get you immediately into "pete.c", searching for "main" on entering vi.
"e -ath" searches for the pattern "ath", finds it in "death", and that's what you get.
"e +10" will get you into "fries" on line 10 (assuming it has 10 lines).
The history file consists of entries composed of a directory name followed by lines of file names (oldest to newest). Each filename is preceded by a single TAB character. The directory names are all absolute pathnames.
In the above example,
"e bigamc"
will prompt you with
"correct to bigmac [y]?"
Answering "n" will not do the correction, "Q" or "q" will quit. If there is more than one possible correction, you will be prompted for each in turn. A response of "N" means that you really want what you typed, and no further corrections will be offered. Any other response (e.g. a RETURN) will do the correction for you.
Suppose you are in the directory /bin with VIPATH set to /usr/include/sys
"e inode.h"
will prompt you with
"/usr/include/sys/inode.h [y]?"
since /bin/inode.h does not exist, but /usr/include/sys/inode.h does. You can say "n" or "q" to reject or quit. "N" will reject the current suggestion and searching for further ones will be stopped. Any other response (e.g. a RETURN) is taken as a yes.
It is handy to have $HOME in your VIPATH, this gives you easy access from anywhere to commonly used files.
If you accept a suggestion, then the file is put into the history. Spelling corrections are not suggested across directories. There is (of course) no need to put "." in your VIPATH. Doing so will just slow things down and cannot possibly be of help. This should be clear, "." is always searched first for the given filename. Putting it into your VIPATH will have it searched twice. The directory names in VIPATH may be separated by white space (including newlines) and colons.
For instance, in a directory of C source you might like to set autoindent and showmatch, whereas in a directory that contained correspondence, you might want neither of these, but wrapmargin and ignorecase instead. Inherited .exrc files allow you to e files in other directories and get the results intended by the .exrc files in them.
There is a drawback however. vi has an option called "modeline" which makes it possible for a malicious user to leave a trojan-horse type file in a directory with a specially prepared .exrc file that turns on "modeline". As a result, if you cd to that directory and vi the wrong file, then the modeline feature allows the other user to execute commands as you. Not nice.
If you set "VISAFEINHERIT", e will make sure that you never get caught by this one. In short, it notices when this could happen and changes directory to avoid the .exrc. There is no need to have "VIINHERIT" set if all you want to do is avoid the security problem. But setting them both gives you the best of both worlds. (See the NOTES for the drawback...)
The history length must be less than or equal to 9 (the code sets it to 8 at present). The problem with having more is that with "e -" you go into cbreak and the first digit entered (say n ) is taken to mean "I want the nth last file". This saves the need for hitting return, but also means that two digit numbers can't be done.
When "VISAFEINHERIT" is set and your command would have resulted in vi going through a foreign .exrc, e will change the name of the file you want to its full path name, and change directory underneath you to your home directory. For example, if user joe says "e file" in /tmp and user mary owns /tmp/.exrc, then the result will be as though joe had typed "e /tmp/file" from his home directory. Of course when he exits vi he will still be in /tmp. Perhaps this could be considered a bug. If you don't like it, you can live with the modeline problem.
The same problem with the directory changing underneath you happens when e inherits a .exrc for you (via "VIINHERIT") - you get changed to that directory while you are in vi.