🚀 go-pugleaf

In gnu.epoch.misc Per Abrahamsen <abraham@research.att.com> wrote:
> 
> Jamie>  - Any key sequence you can generate on your keyboard can be
> Jamie> bound to a command using a logical and consistent interface
> Jamie> that does not rely on pretending you're really dealing with 7
> Jamie> bit integers.
> 
> Neither does FSF Emacs 19.  Characters are represented by 24-bit
> integers, and special keys by symbols.

In FSF19, a key is either: a 7 bit element of a string (with the eighth bit
indicating meta, not a Latin1-non-ASCII character, or maybe it's the other way
around, or maybe it varies, I don't remember); a 24 bit (or possibly 26 bit,
depending on how emacs was compiled) element of a vector, encoding the
modifiers in some nonintuitive way; or a symbol, where the actual characters
of the symbol-name are parsed to determine what modifiers it has.

In Lucid Emacs, a key is a set of modifier names, and a keysym name.  Plain
and simple.  Unambiguous.  No nonintuitive truncation/loss of precision can
occur.  No obscure bugs involving .elc files becoming non-portable.

It's clear to me that users have more trouble making sense of the FSF way;
simply count up how many questions about keybindings you see on gnu.emacs.help
in a week (lots) versus how many you see on alt.lucid-emacs.help (none.)

As for the programmer's interface: in FSF19, an "event" is either an integer,
or a symbol, but usually an integer, making it easy for user code to fall
into the assumption that things are always integers.  In lemacs, input is
always in the form of events, which are never integers, thus preventing this
mistake.  I think this is the right tradeoff.  Using integers for everything
confuses the important distinction between file-characters and input events.

> The event interface for Lucid and FSF are functionally equivalent, the
> difference is mostly a matter of taste.

The APIs are essentially equivalent, but I think there's strong evidence that
the Lemacs user interface (meaning .emacs-file level) is less confusing.  I
also think that the Lemacs API is more robust in terms of preventing
programmer errors that would slip through the cracks in the FSF version.

It's fair to call this a "matter of taste," but I think it's more a matter
of "robustness of interface," which is where my tastes lie I suppose.

> Jamie>  - Input and display of Latin1 chars *just works*, without any
> Jamie> contortions.  (By "just works" I mean things like Isearch as
> Jamie> well.)
> 
> It also *just works* in FSF Emacs 19 (including things like Isearch).

I was under the impression that one could not isearch for keys that were
produced as a result of compose sequences entered using "C-x 6" or whatever
prefix it is that FSF19 uses for this.  I might be wrong, but I saw several
posts where people indicated that they were losing in this way.

And it doesn't "just work" out of the box in FSF19, you have to explicitly
tell it to use Latin1 characters, I presume because of the confusion between
the "meta" bit and the 8th bit.  Possibly this is a minor point (meaning
possibly all of the other internal problems this ambiguity leads to have been
kludged around) but possibly not.  In any event, lemacs has no need for this
distinction.

> With my unbundled `remap' package it also works with Latin2, PC, Mac,
> EBCDIC and about all other 8 and 7 bit character sets.  You can even
> specify different character sets for the keyboard, screen, and the
> buffer.  Lucid lacks many of the primitives needed for doing this.

Tell me what functionality you need, and why you think that representing
almost-but-not-quite everything with integers is important.

	-- Jamie