🚀 go-pugleaf

In article <JWZ.92Aug12134411@thalidomide.lucid.com> Jamie Zawinski <jwz@lucid.com> writes:

>                                             I would consider any of the
>   following changes to be unacceptable, because they would break so much
>   existing code:

>     -  "\M-x" not producing a string of the single character \370
    ...

>   It is a mistake to think of the "meta" key as setting the high bit on a
>   character.  That is an implementation detail.  It is misguided for software
>   which has access to the keyboard beyond what ASCII provides (that is, all X
>   software) to interpret a "meta" chord as meaning "insert a non-ASCII
>   character."  That's what the "Alt Gr" key (which X knows as Mode_shift) is
>   for.  
>	   -- Jamie

This doesn't seem consistent to me.  I certainly agree with the latter
paragraph, however.  I  also think it is a mistake to think of control
as a key  that takes  a normal printable  ascii character and produces
from it something unprintable.  I  realize there is a lot of tradition
behind that view, but  it's a  tradition I'd  rather  forget.  There's
some tradition, in  Zmacs, to have control simply  set a modifier mask
bit, and that's nice.

I'm still using Epoch 4.0, so I haven't  examined the new code, but it
seems to me that the problem is that emacs  (and epoch) are  trying to
cram  more information  in  a small  number of  bits  than  will  fit.
Roughly  two eight  bit  characters are required  to make  things work
nicely  in  my  opinion.   There  are  eight  modification  characters
provided in  X,  Shift thru mod5, and,  on  my  keyboard at least,  94
non-modifier keys.  Admittedly, that  fits in 15 bits, but there might
be some  consideration given to  the  mouse  too.  (A lot of functions
that now read just  characters might be modified to  take mouse  input
also.  As an example I have  modified isearch to accept strings moused
in from the screen.  That's handy.  It would have been nice to be able
to do that directly rather than with a kludged up communication system
between  existing  commands   on  the  mouse  and  a  replacement  for
read-char.)

I suppose that any number of key lookup systems might be used with the
above,  but a particularly simple one  would be to use 8 modifier bits
to look in a (possibly  sparse) keymap for a second  keymap to be used
on the  next 8  bits.  Each  keystroke, and the mouse  possibly, would
produce a total of  16 bits,  in  any event.   One  might  not want to
include shift or  lock in the  modifier mask bits.  One might  want to
take the  meta bit from the first byte  and keep it as the  msb of the
second byte, though personally I wouldn't.  For mouse input one  might
use  a  modifier  mask  bit  and  one  would  need  something  like  a
mouse-read-marker  function that could  be  called to return a  marker
related to the last character read if it  were a  mouse  character.  I
suppose I should build this rather  than just talking  about it, but I
don't have the time at the moment.

 --  Garr