🚀 go-pugleaf

In message <JOOST.92Aug11222437@ori.cadlab.de> Michael Joosten wrote:
>
> Now we have all these fancy features for keybindings, either directly in
> Lucid Emacs or indirectly in Epoch via epoch::rebind-key. But what if I
> want/have to use different X-Terminals or workstations, especially those
> with 'queer' function keys like Apollo DN's ?

Add this to the list of Really Stupid Things that X Left Out.

Possibly the reason that X gives you no way to identify the keyboard hardware
in use is that, philosophically speaking, you shouldn't care, because the
keysyms will be the same from keyboard to keyboard.  If you bind something
to F1, then it will work on any keyboard with an F1 key.

Of course, whatever monster intellect was responsible for the Xsun server
decided that F15 was a really good name for the key which is physically
labeled both "Front" and "L5", so this notion breaks down pretty quickly.

And of course, the propellerheads who designed (and I use the term loosely)
the "keycode/keysym/modifier" model, and that glowing beacon of usability
that we call "xmodmap" conveniently made it impossible to write an xmodmap
script that can function without having special knowledge about either: 
what keyboard hardware you're using, or: its current state of mungedness.

And of course, Sun and MIT can't even agree on what the default keymap
should be for Sun's own keyboard hardware, so it's not enough to know what
keyboard you have sitting on your desk, you also have to know whose server
you're running.

And of course, for those few vendor-defined keysyms that are actually
useful, neither Sun, nor DEC, nor HP, nor MIT can agree on what the names
of them are.  MIT thinks that Sun uses the prefix "SunFA_".  Sun disagrees:
they use the prefix "SunXK_FA_".  MIT thinks DEC's keysyms begin with "D".
Sun disagrees: they think that DEC's keysyms begin with "DXK_".  I don't
know what DEC thinks.  And so on for the various perumtations.  Nevermind
the fact that the keysyms in question serve the same purpose regardless of
the vendor.

> Ok, we could use the vendor string as delivered via XOpenDisplay. But the
> generic MIT servers simply return the same string, not to mention that this
> string is not accessible from EmacsLisp.

That should be accessible from elisp, for all the good it will do you.  For
a laugh, look at the code that xkeycaps uses to intuit what keyboard you're
using.  It's in guess.c (xkeycaps is on export.lcs.mit.edu.)

> Another way I just discovered was to use either xrdb to put a special
> resource in the server or to set via "xsetroot -name " the window name of
> the root window to something 'usefull' (like Sun4, ApolloDN, SGI-Indigo,
> RS6k-MF2, etc).
> 
> The other way is to put something like '*keyboardType: Sun4' in the
> resource database.

Why bother doing this?  At some point you have to decide what kind of
keyboard you're using.  Why not just do that magic in elisp, or just set
an environment variable or something.

> Lucid Emacs has apparently no such facilities for retrieving properties,
> right?

Not in a user-accessible way, but it would be fairly easy to modify some
of the property-munging code in xselect.c to be user-callable.

> Any other ideas? 

Give up hacking and become a tortured artist.  Eat sushi and don't pay.

	-- Jamie