The editor is written in portable "C" and may easily be ported to new machines, provided they have suitable screen and keyboard control.
The only things that change from version to version are filename conventions, available keys for binding, colour support, and support for screen sizes and modes.
On systems with forward slash pathname seperators (UNIX), backslashes in filenames get converted to forward slashes. On systems with backward slashes as pathname seperators (DOS, OS/2 and Windows), forward slashes in filenames get converted into backward slashes. After translation, the filenames get passed to the operating systems.
The DOS AE is limited to 8.3 filenames, but the OS/2, Windows and NetWare versions support long filenames. Of course, UNIX does too.
Keyboard support table :-
|yes||yes||yes||yes||yes||yes #2 #3|
|yes||yes||yes||yes||yes||yes #1 #4|
|yes||yes||yes||yes||-||yes #2 #4|
|yes||yes||yes||yes||-||yes #2 #4|
|yes||yes||yes||yes||yes||yes #2 #4|
#1: Subject to AE recognising the terminal type being used, and the type having a termcap/terminfo database entry with suitable entries in it.
#2: Subject to AE recognising the terminal type being used, and the
type being one for which AE has hard coded knowledge
#3: AE has specific hard coded knowledge of the escape sequences generated for the Alt keys by the linux terminal.
#4: Xenix only supported 10 function keys the last time AE was compiled for it.
A few other obscure keycodes are also supported.
On DOS, OS/2 and Windows searches can be interrupted using the
Elsewhere, its the
The most basic level of keyboard support provided by termcap/terminfo
is support for
and for function keys
If the termcap/terminfo database is incomplete, or your
TERM environment variable is wrong, then even this most basic
level of support may not work fully or at all.
AE for UNIX has a special 'feature' whereby pressing
followed by a key is logically equivelent to pressing Alt and the key together.
This helps out in situations where the Alt keys do not make it to programs,
perhaps because the terminal emulator or windowing system won't pass them on.
^Q can be a problem if operating with
xon/xoff flow control.
^Z are often the suspend and delayed suspend
keys on a terminal.
AE specifically knows the escape sequences for arrows (application and cursor mode) and function keys (F1-F4) in the VT100 terminal (and family) definition.
AE specifically knows the escape sequences generated by function keys in
It does this as emulators/terminals and/or terminfo/termcap definitions often get the distinction between application and cursor mode wrong.
AE knows the escape sequences for masses of keys from
aixterm and IBM
It even knows the variations generated by IBM Internal tool
HFTTERM.EXE for OS/2.
Excellent keyboard support can be obtained using these.
The following additions to your
~/.cshrc file will
improve Ctrl key support, by avoiding the flow control and suspend
key problems explained above :-
stty -ixon -ixoff # Disable ^S ^Q flow control stty susp undef # ^Y no longer suspends stty dsusp undef # ^Z no longer suspends
Note that if you are working on an X-Station, then depending upon your
window manager, some of the keys may be intercepted before AE sees them.
For example, when I run the Motif-Window-Manager,
mwm, I find
@F4 is intercepted before AE sees it, and it is used to
AE knows some of the escape sequences generated for keystrokes from the linux terminal.
The left-function keys (
are known to AE as the Alt+Fn keys
The right-function keys are arranged with the following mapping (as the Sun keyboard doesn't actually have arrow-keys) :-
R7 = Home R8 = Up R9 = PgUp R10 = Left R12 = Right R13 = End R14 = Down R15 = PgDn
Xenix supports 10 function keys.
@Fn keypresses are intercepted by the Xenix
multi-terminal system and are used to switch between sessions.
If the user presses
^~Fn, then AE sees this as
On the iPhone or iPod Touch,
TERM is set to
If you change this, you can cause programs to crash, or even the whole iPhone
to hang so badly a power-off/on is needed.
This is thought to be because the iPhone doesn't deliver a terminfo database
The curses implementation appears to have a hard coded understanding of the
network terminal type.
Colour support table :-
|8 foreground / 8 background||yes||yes||yes||yes||yes||yes #1 #2 #3 #4 #5 #6|
#1: Under AIX, if the termcap/terminfo entry supports it, and you are
running on a
hft terminal, then colour support is
#2: Under Linux (Intel or MIPS), if the termcap/terminfo entry supports it, then colour support is enabled.
#3: Under HP-UX, if the terminfo entry supports it, and the entry was
tic_colr instead of the normal
then colour support is enabled.
#4: Under SunOS, if the terminfo entry supports it, then colour support is enabled.
#5: It is quite normal for the
vt100 terminfo entry not to
include any support for colour, despite virtually all
terminals and emulators supporting the ANSI colour escape sequences.
Also, on some systems the
xterm terminfo does not include
colour support, despite virtually all
xterm terminals and
emulators supporting the ANSI colour escape sequences.
are provided with AE.
These can be added to the system terminfo database by
tic command (or
tic_colr on HP-UX).
#6: Most terminal types don't have colour support, and for these the standard curses support is simply for one of 4 'colours' (none, some or all of which may be supported by your particular terminal) :-
Normal = 0 Underline = 1 support for this often not present Standout = 2 this is usually inverse or bold Alternate = 3 this could be an alternate character set
However, in the general case, given the following defines :-
Black = 0 Flashing = 1 Blue = 1 Static = 0 Green = 2 Cyan = 3 Red = 4 Magenta = 5 Yellow = 6 Bright = 1 White = 7 NotBright = 0
Colour values may be computed as :-
DOS, OS/2, NetWare : value = fg + bg*16 + bright*8 + flash*128 Windows : value = fg + bg*16 + fg_bright*8 + bg_bright*128 UNIX : value = fg + bg*16 + fallback_one_of_4_colours*256
Clearly the portable approach is simply to avoid using flashing and/or
Luckily hex notation (introduced by a
& symbol) can be used
for numbers, including colour values.
Color is not supported running on the iPhone.
AE for DOS supports a wide variety of CGA, EGA, VGA and Super VGA screen modes, including various 43,50 and 60 line modes, and also 132 columns modes. It draws upon the services of the DOS Terminal Handler for its screen handling.
AE for OS/2 can operate in any mode provided by the
interface, including the Super VGA modes detected by the
utility and stored in the
This includes the 132 column modes on XGA-2 for example.
AE for Windows is a regular Console application, and so will work in any of the screen modes supported by Windows.
AE for NetWare runs in a session which seems to have a 80x25 geometry.
AE for EFI supports a variety of screen modes.
AE for UNIX cannot change the screen/window size, and so simply runs with however many lines and columns are currently available.