I've run across a problem using plain ved in an xterm window under
RedHat Linux 6.0. With luck, either someone with a later RedHat release
can say that the problem doesn't exist anymore, or it is fixed by some
current Birmingham file that I haven't downloaded yet. Otherwise I think
it might be a stumbling block for new users, or worse yet an example of
a class of stumbling blocks.
If you start ved (not xved) from the command line in an xterm window
under this version of linux (and I think it will be the same in many
others) ved reads the value 'xterm' from the TERM environment variable
and loads LIB vedxtermkeys.p, which in turn loads LIB ncdxtermkeys.p,
since none of the alternatives SUN, HP9000 or DECSTATION is defined
under linux. However, ncdxtermkeys expects the function keys F1-F4 to
generate sequences beginning "esc [ 1", like the rest of the function
keys, whereas in xterm version 3.3.3.1(88), they actually generate
"esc 0 P" through "esc 0 S". UNLESS, that is, you have set
*VT100*oldXtermFKeys: true
in an app-defaults or Xdefaults file somewhere. (Well of course you
will have done that, won't you?) The xterm man page doesn't actually
explain what is old and what is new, but the name of the resource looked
suspicious, so I tried it and it worked. Presumably, it will mess up
some other program that uses the function keys inside an xterm window
though.
This is a bit naughty on the part of xterm (or RedHat?), because it
contradicts the termcap entry for xterms, which says that the keys
behave the way ncdxtermkeys expects them to, and xterm actually takes
the trouble to put this misleading termcap entry into the TERMCAP
environment variable, regardless of the setting of the oldXtermFKeys
resource.
On the other hand, if you fetch the terminfo entry, which claims to be
newer and better than termcap, although it isn't mentioned in the xterm
man page, you get the non-old xterm settings, again regardless of the
resource.
I've also found that in order for ved to use the keypad keys, I have to
set numlock on (which messes up the use of the mouse in the pine mail
program).
Now none of this is difficult to fix, once it has been diagnosed. In a
way, the trouble is that there are too many ways of fixing it, from
editing the X keyboard mapping file to lines in an individual vedinit.p,
with levels of XTerm translations and poplog library files in between.
If we want potential new users to try out poplog, it's important that
they have a working ved with which to read the documentation, and they
can't be expected to disrupt their existing environments to get one.
So ved has to be as robust as possible against unfamiliar terminal
behaviour. That would suggest to me that, in the absence of an explicit
override, it should look at termcap/terminfo entries first, rather than
as a fallback when there is no named file for the TERM terminal type.
However, the situation described above shows that termcap can't always
be relied on either. Is there a way of checking for what the F1 key
actually generates, apart from asking the user to press it?
Maybe the answer is to make xved be the default version of ved when you
are inside X? But it is noticeably slower to start up on a 400MHz
Celeron, to say nothing of my poor old Sun Ultra at work, and there are
issues of motif or not. Personally, I find plain ved in a linux console
window just great - big, easy to read characters and lightning fast.
But somehow I don't think it is going to have universal appeal.
Stephen Isard
|