[Reposted by A.Sloman at Steve's request: he accidentally only mailed
it to me.]
Aaron Sloman wrote:
> I have been using it in RedHat 6.1 on a Dell Laptop, and have just
> looked and discovered that in my vedinit.p file I have the following:
>
> vedset keys
> ;;; Stuff for linux Xterms (overrides vedvt100keys.p defaults)
> "marklo" = '\^[OP'
> "markhi" = '\^[OQ'
> "clearhead" = '\^[OR'
> "linedelete" = '\^[OS'
> endvedset
I have been doing a bit of reading about xterms, and there seem to be at
least a couple of dozen possible variants. What this code is fixing is
the difference between the MIT X consortium setup - what my RedHat 6.0
manpage refers to as "old" - and the XFree setup. It doesn't help that
all of the different types identify themselves simply as xterm, although
there is a termcap naming system that would permit them to distinguish.
> I also found this:
> if systranslate('LINUX') then
> vedset keys
> ;;; Stuff for linux console
Have you checked whether that is really necessary for your system? When
I use a console window, TERM is set to 'linux' and the libraries from
the distribution end up loading LIB con80x25keys.p, which appears to
work correctly, although I haven't systematically checked every possible
function.
> It looks as if I should
> at least put the first bit into lib vedncdxtermkeys, possibly guarded
> by a test for linux?
It should be put somewhere standard, but I don't think vedncdxtermkeys
is the best place, because the current version probably does accurately
describe the behaviour of NCD X terminals. So either a new file called
something like xfreexterm is called for, or the 'ncd' removed from the
name of ncdxtermkeys. However, the test for which version to use will
be quite tricky, because the behaviour of the keys depends on the X
server of the terminal the user is sitting at, as well as on the version
of xterm that poplog has been started in. So if you have NCD X
terminals in your computer lab, and a user logs into a linux machine
from one, they will want the current ncdxtermkeys behaviour (I think).
In fact, I have an old pc at home that I use as an xterminal attached to
the RedHat machine, and the keys work correctly when I log in from
there. I think it is running an X11R5 X server.
Come to think of it, the xterm might be running on either the poplog
machine or the keyboard machine. That is, if you rlogin to machine B
from an X window on machine A, you will have machine A's version of
xterm, but if you rsh from machine A to machine B, telling machine B to
run an xterm on machine A's display, you will get machine B's version of
xterm.
If a reliable test isn't possible, and we have to choose a default for
linux, then probably the xfree setup is the better default, because
someone who is remotely logged in from an X terminal is fairly likely to
be in an environment where they can get help from a guru. The
physically isolated user who downloads poplog will probably be sitting
at the keyboard of the poplog machine (until the world changes in some
way I am not anticipating). Of course this all assumes that other major
Linux distributions are similar to RedHat in the relevant respects. Are
there any Debian, Suse, Mandrake, etc. users who would like to
contribute to this discussion?
> > I've also found that in order for ved to use the keypad keys, I have to
> > set numlock on
>
> I have never seen that.
Good. Maybe it was just a mistake and they've fixed it. If you run
xev, and press the '8' key on your keypad, with and without numlock,
what keysym does it report? How about if you do 'cat' in an xterm
window and press the '8' key on the keypad with and without numlock?
What gets echoed?
> Finding out which keys generate those sequences may require
> interrogating the user.
>
> Maybe a new user should be asked to press all the function keys in turn,
> and a record of the bindings made in a file, or two files: one for when
> Ved is used, and one for Xved.
I don't know whether all new users should have to go through the ritual,
but it would certainly be helpful to have such a program to turn to if
ved isn't behaving as it should. And of course it should be possible to
run it from the command line for cases where ved is unusable until it
has been run.
Aren't standards wonderful?
Steve
|