🚀 go-pugleaf

In article <LYSTAD.92Aug13103616@m2.dseg.ti.com> lystad@m2.dseg.ti.com (Garr Lystad) wrote:
> 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.  
> 
> This doesn't seem consistent to me.  I certainly agree with the latter
> paragraph, however.

No, these aren't inconsistent.  There is a difference between "things that go
into buffers", which for the sake of argument I'll call "characters", and
"things the user types", which I'll call "keys."  On every keyboard in the
world, even the dumbest ASCII keyboard, you can type any chord of keys.

In an ASCII world, when the only connection that a program has to the user is
a stream of 8-bit (or 7-bit) bytes, the keyboard hardware itself does the
mapping from keys to characters, so all Emacs can see is the characters, not
the keys.  

When you've got access to the keystrokes directly, it's much more interesting
for an editor to bind commands to *keys* instead of *characters*.

However, there still needs to be a mapping between keys and characters.  
Long precedent dictates that you use the high bit to represent meta when
downgrading a key to an ASCII-ish character.

It would also be reasonable to convert a "meta" key sequence to a
two-character ASCII sequence beginning with escape; there's precedent for
that encoding as well.  But the problem is that emacs has long been using
the other encoding for this particular case, and changing it now will 
probably break a lot of code.  Especially given the current implementation
of keymaps.

> 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.

Right, Zmacs did that for keys, but used an 8-bit ASCII-like encoding when
translating keys to characters for insertion into buffers.

> 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.

Well, that's one possible implementation.  In lemacs we no longer represent
keys as integers, we represent them as a symbol (derived from the X keysym)
and a set of modifier bits.

> 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.

We changed keymaps to be an opaque type; they use a more complicated internal
representation now than a simple vector or alist, they're more like hash
tables.  It has been a minor portability problem that we changed keymaps in
this way, but I think that any change, even the one you're describing, would
result in a similar change of representation.


In article <BLK.92Aug13105651@vanity.mitre.org> blk@mitre.org (Brian L. Kahn) wrote:
> 
> Emacs has a tradition of interpretting "\ev" and "\M-v" to be
> identical.  I suggest it is time to make this interpretation optional.

I think you're talking about the key sequences `escape' `v' and 
`meta-v' rather than the string of 8-bit bytes that you typed above.
If so, I agree.  If not, I think it would break too much code.

> I've got enough bindings that I don't need to disrupt the association
> between meta and escape, but I can see why others might want to.

Another reason you don't want to disrupt the association between meta
and escape (at least as far as define-key and the string read-syntax
are concerned) is the existing code that it will break, as the Epoch
patches that started this thread demonstrated.

> If we bind the Meta key the same as the ESC key by default, then \ev
> and \M-v still work the same, as expected.  If someone wants to use
> the meta key for inserting 8bit characters, bind meta to a map filled
> by self-insert-key-8bit and everyone is happy.  Yes?  No?

Meta is the wrong thing to use for inserting 8-bit characters, because
that makes it impossible to execute meta chords in conjunction with 8-bit
characters.  Remember, some keyboards have unshifted keys which generate
what those in a US-ASCII world might call "meta" characters.  I think
that underlying this statement is the assumption that emacs is seeing
some 8-bit quantity and has to interpret it.  This is no longer the case
when you're running a window system: emacs knows where your *fingers* are.

> BTW, it is nice to see Jamie contributing here, even though lemacs is
> in some sense competitive with epoch.

Hey, I just want to have a really good editor.  I don't care who writes it!

	-- Jamie