README for vile, version 7.0
-----------------------------
vile is a text editor which is extremely compatible with vi in terms
of "finger feel". in addition, it has extended capabilities in many areas,
notably multi-file editing and viewing, key rebinding, and real X window
system support.
the authors of vile are Paul Fox, Tom Dickey, and Kevin Buettner.
many patches have been contributed by a lot of users. we thank them.
more recent additions to this README appear near the bottom. that is, most
of the newest stuff is at the end, not up here where you are.
visit
ftp://ftp.clark.net/pub/dickey/vile
ftp://id.wing.net/pub/pgf/vile
to be sure it's still the latest.
impatient? just type "./configure; make", and get a cup of coffee, decaf
if necessary.
want X11 support? you'd better look at README.CFG, although
"./configure --with-screen=x11"; make" may well do what you want.
if you like vile, and wish to be informed of new releases, let me
know -- i maintain a mailing list for that purpose. don't worry -- the
volume won't fill your inbox.
paul fox, pgf@foxharp.boston.ma.us (original author)
kevin buettner, kev@primenet.com
tom dickey, dickey@clark.net (current maintainer)
------------------------------------------------------
Send bug reports to
vile-bugs@foxharp.boston.ma.us
Requests to be put on the announcement list should go to
vile-announce-request@foxharp.boston.ma.us
------------------------------------------------------
original README, from February, 1992:
VILE -- VI Like Emacs: a vi workalike put together from Micro-Emacs by Paul Fox
-------------------------------------------------------------------------------
This editor grew out of a frustration that although lots of
eager programmers have tackled rewrites of Emacs, with new and
better features (not to mention free source), I've not seen
anything similar done with the Second True Editor. (The
First, of course, being /bin/ed)
So I took a copy of MicroEmacs 3.9 (which I've since
discovered was out of date, unfortunately) and turned it
into a vi "feel-alike". It retains the multiple
buffer/multiple window features of uemacs, but the
"finger-feel", if you will, is very much that of vi. It is
definitely not a clone, in that some substantial stuff is
missing, and the screen doesn't look quite the same. 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. THIS IS NOT A "CLONE"! But it feels good.
(Put another way, the things that you tend to type over and
over probably work -- things done less frequently, like configuring
a .exrc file, are quite different.)
This is the second really public release of vile. Users of
previous versions will hopefully find many new features -- see the
CHANGES file for details.
The collective developers of Micro-Emacs should be
complimented that the changes were as easy as they were. The
code was pretty clean and well designed before I started on
it. I'm not sure that the same can be said anymore...
The major benefits over standard vi include:
- multiple files open at once
- multiple windows on the screen
- a larger set of operator commands
- the possibility of porting to your favorite micro.
- "next error" cursor positioning after compilation
[ - infinite undo -pgf 7/93 ]
Of course, it _may_ lack some of vi's reliability. :-)
[but not much -- it's _very_ stable these days. -pgf 1/95]
Take a look at vile.hlp for more information about features
and differences.
In general, I suspect that the quality of the code is roughly
on a par with MicroEmacs. I've been using vile regularly under
both SunOS and 386 UNIX for almost two years [more like 5 years
now, on a lot more platforms than that -pgf 12/94], with no major
problems (that haven't been fixed). Version three was built and
used by many others on the net, and their feedback was invaluable.
I think all of the reported bugs have been fixed, and hopefully not
too many new ones introduced.
I have not run this much on a small system, and not much at all on
DOS. Pete Rusczinski has done an excellent job of porting
version three to DOS -- his changes are now incorporated here (as
of version 3.20), but since in general the DOS version has been
less well exercised than the UNIX version, it probably harbors
more bugs.
Hope you enjoy --
Paul G. Fox June, 1991, and February, 1992
p.s. By the way, I'm _not_ the same Paul Fox who wrote Crisp, the Brief
work-alike.
-----------------------
September, 1992
I don't have much to add to the original README -- vile has gotten a lot
better since I first released it, thanks to a lot of users and a lot of
bug reports. It compiles and runs without modification on most major UNIXes,
and under DOS. It offers vi finger feel, and most (not all) of its features.
I hope it fills someone's need out there. -pgf 9/92
(Special thanks to Dave Lemke and Pete Rucszinski, for X and DOS support,
and (in no particular order) to Eric Krohn, Willem Kasdorp, J.C.Webber,
Warren Vik, Julia Harper, Chris Sherman, Thomas Woo, Yanek Martinson, Miura
Masahiro, Tom Dickey for lots of bug reports and suggestions and patience.)
------------------------------
April, 1993
Well, here's an update on vile. The first release was a long time
ago (a couple of years?). Tom Dickey has been contributing a _whole_ lot
of good changes. vile now runs on VMS, and is much more stable on DOS
thanks to Tom. For me, vile is becoming an "old" program -- I first worked
on it in 1989 sometime. So it's been fun to have someone contributing
fixes so energetically. Thanks Tom.
One thing that's changed since I first started vile is that "lots of eager
programmers" have now tackled rewrites of vi. There are several good work-
alikes out there: elvis (the "king" :-), xvi, vim, stevie, and recent
versions of vip-mode in GNU emacs. [add "nvi" to that list. and whatever
happened to xvi? -pgf 12/94] From what little I've used any of
these, they all seem like real good programs. vile feels different from
most of them, mainly due to its roots in MicroEmacs. You may or may not
like it. If you don't, try one of the others. There's certainly no reason
to not have a vi-like editor on just about any machine you choose. (yeah,
I know -- I'm assuming you _want_ a vi-like editor... :-) Enjoy.
Oh yes -- building it. On UNIX, type "make", and choose one of the predefined
targets. Like "make linux". [ not anymore -- use "configure; make" -pgf 12/94]
DOS makefiles are named after the compiler they support: makefile.tbc for
Turbo-C, makefile.wat. There is support in "makefile" for Microsoft-C, but
it's next to useless -- if anyone puts together a good "nmake" makefile,
could you pass it along? [that support isn't there anymore. -pgf 12/94]
The Watcom C/386 v9.0 compiler should also work -- the makefile to use is
makefile.wat.
The latest version of vile is usually available for ftp at "ftp.cayman.com",
in the pub/vile directory. [not anymore -- it's at "id.wing.net" in the
"pub/pgf/vile" directory. -pgf 12/94] Sometimes there's a compiled DOS
binary there too. I don't maintain a mailing list, or anything like that
to inform folks of new releases -- you just sort of have to check once in a
while, or send me mail... [ I've set up a mailing list -- contact me to be
added -pgf 7/93]
paul
------------------------------
July, 1993
More new features: infinite undo, modification time checking, and, at
long last, primitive support for the :map command. [:map is now fully
functional -pgf, 12/94] I've also received patches that let vile compile
for DOS with the DJ GCC compiler. Have I mentioned filename completion?
Tom Dickey provided that and variable/modename/command completion too.
If you would like to be informed, via email, of new vile releases (bearing
in mind that the newest release may be _more_ likely to be buggy, rather
than _less_), please send me mail, and I will add you to my list. The email
will probably contain a capsule summary of the most recent changes to the
code.
Thanks to Tuan Dang for the Watcom and DJ GCC work. I don't know much
about djgpp, the DOS port of djgcc, but take a look at makefile.djg.
pgf
-------------------------------
March, 1994
The X support in xvile has been given a huge boost with contributions from
Kevin Buettner -- scrollbars, Motif widget support make it feel like a real
application... We now have rectangular regions. DOS support is getting
better all the time. The major version number got bumped to 4 somewhere
along the line, because Tom and I were getting tired of 3. There are quite
a few new "modes", some to support vi functionality, some altogether new.
We should have keyboard selections and highlighted regions soon...
pgf, pgf@foxharp.boston.ma.us
-------------------------------
December, 1994
hmmmm -- lets see. new stuff. see the CHANGES and help files for details.
- vile is now completely autoconf'ed -- you should be able to type
either "./configure; make" or "./configure --with-screen=x11" to build
it on any (unix-like) platform.
- :map and :map! are now much more complete, but still by no means
done. expect to have to edit your favorite macros to make
them work.
- :abbr now works.
- along with proper :map support comes proper function key support.
function keys defined for your terminal in the termcap/info database
are now premapped and can be bound to as #-1 etc. so those of
you with ESC [ 10 ~ style function keys should be happy now.
- mouse clicks which move the cursor now count as proper motion
commands in both xvile and vile-in-an-xterm. this means, for
instance, that '' or `` will get you back to where you were before
you clicked the mouse, and you can apply operators to mouse
movements. for example -- click the mouse somewhere, hit 'd' to
start a delete operation, and click the mouse somewhere else. the
text between the two mouse-click locations will be deleted.
- on-line help (just a single line) for every function, available
with describe-{bindings,function,key} commands.
- new modes to better control beeping and the "working..." message.
- autowrite mode now supported, on a global or buffer-by-buffer basis.
- popup windows now adjust their size to their contents -- less screen
space is wasted for small window, and more is used for big windows.
- file and command completion is now more emacs/bash/tcsh-like, in
that possible choices are shown when you hit a second TAB key. this
can be tuned via a new mode, "popup-choices"
- "quoted" motions, which highlight the text they will act on. type
a 'q', and start moving around, then type another 'q'.
- various fixes to the macro language, for core dumps and usability.
- file.bak and file~ backup files now supported.
- infinite (?) screen sizes should now be supported under X.
- it's now possible to break lines by putting ^M in the replacement
pattern.
- selections, the modelines, and the cursor, under xvile, can all
have different colors.
- color support for termcap, at least on the linux console.
- put'ing from registers (i.e. 'p' and 'P' commands) should be much
faster.
- multiple (error) messages arising from running a macro or a startup
file will now accumulate in a new popup window.
- a simple, probably incomplete file-locking protocol is available,
but is not compiled in by default. the organization which
contributed the code (Baan Development) uses it to aid their
multi-user development. turn on OPT_LCKFILES in estruct.h and
"set usefilelock" in your .vilerc to play with it.
- Windows NT support -- console mode only. anyone want to port this
to the Windows95 console? it's probably not hard, though i haven't
looked into it very hard.
- lots of bug fixes
-------------------------------
Febrary, 1995
xvile now supports color attributes, which means we can do some
primitive syntax coloring of C programs, using the external filter,
"c-filt". this is still pretty new stuff. expect it to get better
with age.
-------------------------------
November, 1995
lots of new users in the last year, due to better advertising
and inclusion in some of the big linux and freebsd archives.
support for NT and OS/2 has gotten much better, and lots of
little bugs have been fixed, and features added. Win32 support
is very good these days, thanks mostly to the efforts of Rick
Sladkey.
-------------------------------
June, 1996
gee, i don't remember _what_ we've done recently. enjoy.
-------------------------------
September, 1996
tom dickey has volunteered to take over releases, and maintaining
"official" sources. i'll still contribute, but more as part of the
"audience". tom has done a _huge_ amount of work over the years
on vile -- i _really_ appreciate it... -pgf
-------------------------------
$Header: /home/tom/src/vile/RCS/README,v 1.59 1997/02/28 11:12:39 tom Exp $
-------------------------------
README.CFG
----------
This file describes the steps which are needed to configure and make either
vile or xvile. See the file README for a blurb on what (x)vile is and how
great it is :-). The file INSTALL contains generic information on the
process of configuring and building programs which (more or less) conform
to the GNU coding standards. You might want to consult that document for
more information.
Building vile
-------------
To build vile, enter the following command from your shell:
./configure; make
If you'd like to examine makefile and config.h prior to making, split these
steps up as follows:
./configure
make
If you are unfortunate enough to be running on a platform in which some
part of the above process does not work perfectly, you might well want to
modify makefile to add references to obscure libraries or non-standard
library locations.
[ At least one version of bash running on Linux (and perhaps other)
systems will cause the configure script to produce invalid results.
Specifically, if you're running version 1.14.3 of bash consider
upgrading to a newer one. ]
Modifying makefile is not recommended because your changes will be lost
should you run configure again. Many configuration options can be
set externally to the configure script or the makefile. For instance,
if you'd like to change some of the flags passed to the C compiler, try
doing it like this:
make CFLAGS=-O2
Or, this can be done when running the configure script instead -- try:
CFLAGS=-O2 ./configure (sh, ksh, bash)
or:
(setenv CFLAGS -O2 ; ./configure) (csh)
If you need to suppress your optimizer (which is invoked as -O by default),
because it's known to be buggy, use CFLAGS=" ". [ One combination
thought to be buggy is AIX 3.2.5 with gcc 2.6.0. ]
The configure script will favor using gcc on your system if available. This
is usually fine, but if gcc was not installed correctly (or your environment
isn't quite right), it can be disastrous. You can override the choice
of compiler with:
CC=cc ./configure (sh, ksh, bash)
or:
(setenv CC cc ; ./configure) (csh)
Likewise, extra link libraries can be added by setting them in LIBS before
running configure.
Building xvile
--------------
You must decide which version of xvile you want to build. To a certain
degree this decision may be forced upon you by which libraries you have
on your machine. There are three different versions you can build.
1) X toolkit version: This version uses only the X toolkit to implement
scrollbars and the window resize grips (meaning _vile_ windows, not X
windows). As a consequence, it should only require the X toolkit library
(-lXt) and the Xlib library (-lX11). (Don't worry if you don't know what
these are or where these are; the configuration script will probably be
able to find them.) The scrollbars in this version look much like those
found in a standard xterm. We recommend that you try this version out
first as it is superior in some respects to the other versions which use
fancy widget sets. To configure this version, enter the following command:
./configure --with-screen=x11
2) Motif version: This version uses the Motif widget set to implement
the scrollbars and (vile) window resize pane. To configure the Motif
version, enter the following command:
./configure --with-screen=motif
3) OpenLook version: Uses the OpenLook widgets to implement scrollbars. Since
OpenLook lacks a pane widget, resizing (vile) windows is pretty cheesy. Still,
if you are running olwm or olvwm, you might well want to run this version
so that xvile will look the same as your other applications.
./configure --with-screen=openlook
After configuration, you may look at the makefile or config.h if you wish. You
can finish making xvile by entering the following command:
make
On some systems it seems to be sometimes necessary (?) to have X_LIBS set
to -static prior running configure, i.e, use either:
X_LIBS=-static ./configure --with-screen=openlook
for sh, ksh, and bash. Or:
(setenv X_LIBS -static ; ./configure --with-screen=openlook)
for csh and tcsh.
Installing (x)vile
------------------
Installation of (x)vile is simple. Obtain the appropriate privileges (become
superuser if you have to), and enter the following command:
make install
If you have ever installed an older version of vile, you should probably
check to be sure the old help files are gone. They used to go to a
different place (by default) than they do now. It can be most confusing
to use an older version of the help file with a newer version of the
program, and unfortunately, older help files didn't have version numbers.
We realize that not everyone has superuser privileges on the machines on
which they wish to build (x)vile. By default, the executables will be
installed in /usr/local/bin. vile.hlp will be installed in /usr/local/lib.
vile.1 (the manual page) will be installed in /usr/local/man/man1. If you
lack superuser access or write access to /usr/local, you will want to
change the installation location. You may do so by using the --prefix
option to "configure". Suppose you wish to have xvile installed in
$HOME/bin (your home bin directory). You would issue the following
configuration command:
./configure --with-screen=x11 --prefix=$HOME
The file INSTALL has more information on installation and on the --prefix
option to "configure". (If you don't feel like rebuilding (likely), you
can also edit the makefile and change the "prefix", "bindir", or "libdir"
definitions -- remember that your changes will be lost next time you run
configure.
Building in a separate directory
--------------------------------
If you are building (x)vile for several machines or want to perhaps
simultaneously build and try out the various versions of xvile, you will
probably want to configure (x)vile to build in a directory different from
where the source resides. This requires that you have make program which
correctly uses the VPATH variable. GNU make does this well, others may
or may not.
Suppose that the source resides in vile-src. At the same level as
vile-src, you might perhaps create a directory called vile-x11-sunos to
indicate that you are building xvile on a platform running sunos. You
would then cd into this directory and issue the following configuration
command:
../vile-src/configure --with-screen=x11
Another directory at the same level as vile-src might be named vile-sunos
to indicate that you are building vile on a platform running sunos. After
you cd into this directory, you'd then issue the following command to
configure ordinary vile.
../vile-src/configure
The "make" step in each case is the same as described above; you simply
issue the command:
make
to finish making (x)vile.
This process is described in more formally in the INSTALL document. As
described there, you will need to use a version of "make" which supports
the VPATH variable. And it must support it _correctly_. Again, GNU make
does this. A lot of older "make"s don't.
------------------------
$Header: /usr2/foxharp/src/pgf/vile/RCS/README.CFG,v 1.10 1995/11/09 23:16:09 pgf Exp $
------------------------
Running vile on a PC... ------------------------------- vile can be built for DOS, OS/2, Windows/NT or Windows/95 DOS information ---------------- under DOS, you're best off using a DOS extender of some kind. either the Watcom or DJGPP compiler suites may be used -- DJGPP gives you a faster executable, but the Watcom compiler is about 10 times faster. you can use Turbo or Borland C as well, but neither of those support an extender, so you end up only being able to edit files that fit in memory. if you do this, be sure to '#define SMALLER 1' in estruct.h, to save as much code space as possible. if you build with Watcom, you'll need to have both vile.exe and dos4gw.exe in your path to run vile. if you build with DJGPP, you'll need to have both vile.exe and go32.exe in your path to run vile. newer versions of DJGPP may rely on DPMI, and you might need cwsdpmi.exe instead of go32. experiment. have fun! let me know about bugs/oddities when you use vile on a PC -- i probably don't use it as much as you do. (it's quite possible that the DOS makefiles are a little out of date -- refer to the UNIX makefile (makefile.in) for correct current list of source and object files.) oh -- there are three possible screen drivers in the source distribution that should work, with varying degrees of success: borland.c (need #define BORLAND in estruct.h or makefile): this uses the "conio" routines that come with Turbo C or Borland C++. Again, the trouble with this under DOS is that the Borland compilers don't produce a dos-extender 32 bit app, so you're _severely_ limited as to filesize. but the DJGPP libraries emulate the borland screen i/o routines, so this screen driver is used there as well. ibmpc.c (need #define IBMPC in estruct.h or makefile): goes straight to the video controller and the screen, should support most popular video modes on CGA/EGA/VGA cards. this is fine under regular DOS, but starts causing problems in a Windows DOS-box, due to its direct video accesses. ansi.c (need #define ANSI in estruct.h or makefile): uses ANSI.SYS. this may be more portable than ibmpc.c, since it relies on the ansi driver for its cursor/scrolling/color services. if you can change the resolution of your screen (to 43 or 50 line mode) with your ansi driver, just use the "screen-rows" and/or "screen-columns" vile commands to make its idea of the size match your physical screen, and you'll be all set. (i've only tested it with a free/public replacement program called NNANSI. i got my copy from a simtel mirror. i can probably find you a copy if you need it.) OS/2 information: ----------------- i believe vile can be built with the Borland compiler, or IBM CSET. be aware that vile is NOT a PM program. the two builds use the borland.c or os2vio.c screen drivers, respectively. WIN32 information (Windows NT and 95): -------------------------------------- either Visual C++ or the Borland compiler can be used. see the makefiles for details. the screen driver is ntconio.c -- this is a console-mode only port. -------------------------------------------------------- paul fox, pgf@foxharp.boston.ma.us (home) ------------------------ $Header: /usr2/foxharp/src/pgf/vile/RCS/README.PC,v 1.11 1996/07/11 15:07:39 pgf Exp $ ------------------------
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.