In addition, Elvis has been reported to work under a few other operating systems. It isn't officially supported under these yet.
I tried to make it use the spooler program, PRINT, but failed. The first problem I ran into was the fact that PRINT can't read data from stdin; it must be given the name of a file. To work around this problem, I modified the osmsdos/osprg.c file to allow $1 in the command line to be replaced by the name of Elvis' temporary file that contains the print data.
This lead to the the second problem: PRINT doesn't make a copy of the file, and Elvis deletes the temporary file as soon as PRINT exits. Since PRINT exits before the file has been printed completely, this means that the file is deleted before PRINT is through reading it. The print job is truncated. I was unable to find a way around this problem, so I gave up and just set lpout=PRN.
cl /c ($1?$1:$2)", which is appropriate for MSVC++ 1.5.
This way, you can run :cc without arguments
to compile (but not link) the current source file.
If you supply arguments, they'll be used instead of the filename.
make". You might consider changing it to
"nmake -f ($1?$1:basename($2)".mak")", would allow MSVC++ 1.5
to compile "foo.c" via the "foo.mak" makefile, unless you invoke
:make with command-line arguments naming
a different makefile.
~\dotelvis;BIN\data;BIN\doc", where BIN is the directory
where elvis.exe resides.
Note that elements of the path are separated with semicolons.
The ~ character is replaced by the value of the
home option, which is also usually the
name of the directory where elvis.exe resides.
If you're going to be editing a large file, you may want to increase the block size. The only way to do that is to invoke Elvis with a "-b2048" argument. You can't change it via ":set blksize=..." because by then the session file would have already been created with the old block size. Once Elvis starts, you should probably ensure that the blkcache is no more than 6 or so, or else Elvis may run out of memory unexpectedly.
If TERM is set to "dosansi" then Elvis will output escape sequences which are supported by the ANSI.SYS driver. This isn't recommended; ANSI.SYS is just as slow as the BIOS, and it isn't as powerful so Elvis is forced to redraw the screen instead of scrolling it, in some circumstances.
If TERM is set to "nansi" then Elvis will output escape sequences which are supported by more capable drivers, such as NANSI.SYS and FANSI.SYS. These drivers usually bypass the BIOS, so they are very fast. If you're looking for a way to speed up Elvis, this is probably your best bet. The Web URL for these drivers is listed in the Tips chapter.
Elvis also supports "vt220" which use DEC VT-220 escape codes, and "ansi" which uses true ANSI escape codes for both input and output. "ansi" doesn't work with ANSI.SYS!
config.h file
and recompile Elvis. Normally the missing features are:
Windows doesn't allow a single program to have both a text-mode interface
and a graphical interface, so we include two separate versions of Elvis.
ELVIS.EXE is the text-mode version, and WinElvis.EXE is the graphical version.
Run "elvis -G?" for a list of the text-mode user interfaces
supported; you will generally want to use the "termcap" interface. The graphical version, of course, is unable to output such a list.
It supports two user interfaces, named
"windows" and
"quit".
elvis.exe, or "windows" in WinElvis.exe.
The "windows" printer type is only available in WinElvis; it causes Elvis to use the standard Windows graphics-oriented print spooler. This is a very slow way to print, but it is portable and produces good-looking output.
cl /c ($1?$1:$2)", which is appropriate for MSVC++ 2.0 or later.
This way, you can run :cc without arguments
to compile (but not link) the current source file.
If you supply arguments, they'll be used instead of the filename.
make". You might consider changing it to
"nmake -f ($1?$1:basename($2)".mak")", would allow MSVC++ 2.0
(or later)
to compile "foo.c" via the "foo.mak" makefile, unless you invoke
:make with command-line arguments naming
a different makefile.
~\dotelvis;BIN\data;BIN\doc", where BIN is the name of the
directory where ELVIS.EXE resides.
Note that elements of the path are separated with semicolons.
The ~ character is replaced by the value of the
home option, which is usually
C:\users\default for WindowsNT.
Unlike MS-DOS, Win32 doesn't pass the full pathname of the .EXE file as an argument to the program. So the when the Win32 version of Elvis starts up, the first thing it does is search for ELVIS.EXE in your execution path. It must do this in order to find the value to use as BIN.
When Elvis starts, it creates a separate buffer which is the same size as the window (except under Windows95 which has bugs in this area). Elvis does this mostly so the scrollbar will go away. If you change the buffer size while Elvis is running, Elvis will adjust the size of the window to match the new buffer size, and then redraw the text to take advantage of the new screen size.
You can change the console buffer's size by setting the ttyrows and ttycolumns options. In WindowsNT, you can also change the size via the console's Properties dialog.
When you exit Elvis, the console will revert to its original buffer and original window size.
In Elvis (text mode), the mouse should work both in full-screen mode and in a window. Dragging with the left, right, or both buttons pressed is will select characters, whole lines, or a rectangular block, respectively. If you have a three-button mouse and the appropriate driver, dragging with the middle button pressed will also select a rectangular block. Clicking the left button will cancel a pending text selection, and move the cursor. Clicking the right button will move the cursor; if a text selection is pending, it will be extended to the new cursor position. Double-clicking the left or right button will follow a hypertext reference or return from one, respectively.
There is a weird bug in WindowsNT's text-mode mouse support. If, when the console is shown in a window, part of that console is located off-screen, then the mouse won't be able to move there, even if you're currently in full-screen mode! Since WindowsNT will sometimes resize your console when you switch between full-screen and windowed modes, this might not be obvious. But if the mouse refuses to move onto part of your full-screen console, I suggest you switch back to windowed mode and reduce the size of your font there. When you switch back to full-screen mode again it will look exactly the same, but the mouse should be able to go where no mouse has gone before.
mount
utility to define a mount table, then Elvis will try to use it.
I say "try to" because that table is maintained in the Win32 registry,
and although Elvis can handle the current version of Cygwin, later versions
may move the mount table to somewhere that Elvis can't find.
Elvis doesn't use the normal Cygwin functions for mapping file names via
the mount table, because I didn't want to make Elvis be dependent upon
the CYGWIN.DLL library;
instead, Elvis uses standard Win32 registry functions to read the mount table.
use t
Only Elvis has been modified to use the mount table.
The other utilities (such as ctags,
fmt, and Elvis' version of ls)
will ignore the mount table.
Also, even Elvis will ignore it with respect to the names of the session
file and temporary files (the session,
sessionpath,
and directory options).
Some problems have been reported when running the text-mode version of
Elvis via the bash shell.
I'm trying to fix that.
The graphical version of Elvis works fine, though.
There are four separate versions of Elvis for OS/2, each one compiled
with slightly different features.
The version that most people will want to use is named elvis.exe.
It uses the vio user interface,
and includes network support so Elvis can read via HTTP,
and read or write via FTP.
But a few OS/2 systems might not have the TCP/IP libraries installed,
so the normal elvis.exe version won't work there.
A stripped-down version named elvis-no-tcp.exe is provided
for use on those systems.
It also uses the vio user interface,
but it omits the network support so it doesn't require any special libraries.
There is also a version named elvisemx.exe which supports the
termcap user interface
in addition to the standard vio interface.
This should allow you to run Elvis over a telnet connection.
However, it requires the EMX.DLL library,
in addition to OS/2's TCP/IP libraries.
(See the Tips chapter for EMX links.)
The last version is named elvisx11.exe.
It supports the x11 graphical
interface in addition to VIO and termcap interfaces.
For instructions on how to run Elvis with X11 under OS/2,
see section 9.3.1 below.
It requires the TCP/IP and EMX libraries, and at least some parts of the
XFree86 package.
The following lists the OS/2-specific quirks that are common to all versions:
gcc -c ($1?$1:$2)". You may want to change it.
This way, you can run :cc without arguments
to compile (but not link) the current source file.
If you supply arguments, they'll be used instead of the filename.
make $1".
~\dotelvis;BIN\data;BIN\doc", where BIN is the name of the
directory where elvis*.exe resides.
Note that elements of the path are separated with semicolons.
The ~ character is replaced by the value of the
home option.
But the termcap interface is still supported, if compiled using EMX/GCC and linked against EMX.DLL both the usual "vio" and a termcap based interface are available.
You should be able to run elvisx11.exe with XFree86
without any trouble.
You can also run elvisx11.exe under PMX provided you install
a few critical files from XFree86, as described in the following steps.
(Note that these steps are only necessary to run elvisx11 under PMX.
If you're using XFree86 then you can skip this.)
unzip xf32bin
copy XFree86\libx11.dll e:\emx\dll
md e:\emx\XFree86
md e:\emx\XFree86\lib
md e:\emx\XFree86\lib\X11
xcopy XFree68\lib\X11\locale e:\emx\XFree86\lib\X11\locale\ /s
set X11ROOT=e:/emx
Since Elvis (and vi, for that matter) were originally designed and written for UNIX, there aren't many quirks that show up for generic UNIX. Most of this section will describe the quirks of individual UNIX versions.
configure script; if /usr/bin/lp
exists then it will use "!lp -s", else it will use "!lpr".
~/.elvis:/etc/elvis:/usr/share/elvis:/usr/share/elvis/doc.
The /usr/share/elvis member of that path can be set via the
--datadir=directory flag to the configure
script.
The /etc/elvis directory is where you should put any
system-wide modified versions of the configuration files.
Don't edit the standard versions in /usr/share/elvis.
need.h and need.c files;
they contain implementations of many such functions.
To use Elvis' version of the missing function, edit the config.h file
and change "#undef NEED_XXX" to "#define NEED_XXX".
In all of the officially supported Unix variants listed below,
the configure script automatically selects any necessary
NEED_XXX macros.
configure script works around most of the quirks of individual
UNIX versions.
Here, I will describe what configure does, or fails to do, for
each type of UNIX.
uname
command.
However, their configuration is quite different, so the configure
script distinguishes between them by looking at the revision number output by
"uname -r".
The SunOS port uses BSD's sgtty ioctl calls, instead of the POSIX calls, even though SunOS supports the POSIX calls. This choice was made because differences in signal handling were preventing the SunOS port from responding to window resize signals.
Solaris2 seems to have a bad implementation of rlogin, at least on the system where I tested it. It couldn't handle 2000-character write() calls. Because this is a communication issue, and not purely a Solaris issue, I decided to reduce the size of the output buffer for all systems to 1500 bytes.
The SunOS port uses termcap because I prefer it. The Solaris port uses terminfo because Solaris doesn't seem to have a termcap library.
Sun's normal C compiler, "cc", only supports the old K&R syntax, not ANSI syntax. Some of your standard (non-Elvis) header files may include a "const" declaration which K&R doesn't understand, so if you aren't using GCC then the configure script will append "-Dconst=" to the value of the CC macro in your Makefile, so the "const" keyword will be ignored.
If you configure Elvis to support X-windows, and your LD_LIBRARY_PATH
environment variable doesn't contain an X11 library directory, then
the configure script will output a warning message telling you
how to set that variable.
However, you might not need to set it; try running Elvis without setting
it first.
The primary weirdness is that it uses tinytcap.c (by defining NEED_TGETENT in the config.h file) instead of the real terminfo functions. I suggest you try compiling without NEED_TGETENT.
configure will try to use the shlicc2 compiler if it
is available, so Elvis can use shared libraries.
Interestingly, the BSD port is configured to use POSIX ioctl calls instead
of BSD's own sgtty calls.
This may be a mistake.
If Elvis fails to adjust when you resize your xterm,
then I suggest you run "configure --ioctl=sgtty",
and recompile.
uname" command)
to match the network node name.
If uname reports a brand of Unix that configure doesn't recognize,
then configure will inspect the files on your system for evidence
that you're running SCO Unix/ODT or SCO Xenix.
If that test fails, you'll need to give the OS name on the the command line
when invoking configure (e.g., "configure sco"
or "configure xenix").
When using an ANSI compiler, SCO seems to require extern declarations of the termcap functions. I added those declarations to the end of the "osunix/osdef.h" file.
configure --ioctl=sgtty".
Without the "--ioctl=sgtty", Elvis would be configured to use the POSIX
termios ioctl() calls, which don't work quite right under MiNT.
If you would like to port Elvis to another operating system, please contact me first. I can send you some notes I have about how the OS-dependent functions in the os*/*.c files should behave, and also how the GUI functions should behave. That's normally all you need to write in order to port Elvis to a new operating system.
A Macintosh port is currently underway. I still need volunteers to port it to VMS and OS-9. I would also welcome a port for any other popular system.