🚀 go-pugleaf

I don't think that the patches Epoch is using for 8-bit support can be made
to work sensibly without a serious redesign.  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
  -  "\ex" not producing a string of the two characters \033 \170
  -  define-key interpreting the strings "\370" and "\033\170" differently
  -  lookup-key interpreting the strings "\370" and "\033\170" differently

In GNU Emacs, keymaps are tables indexed by 7-bit ASCII codes.  "Meta"
characters, which are sometimes implemented by turning on the high bit of 
an ASCII code, are stored in a sub-keymap which is indexed under the "escape"
character.

What these patches do is make keymaps be indexed by 8-bit codes *as well as*
the old method of using a sub-map indexed by escape.  This is paradoxical.
You can't have it both ways.

In Lucid Emacs, we have reimplemented keymaps so that they are not indexed by
7-bit or 8-bit codes, but rather by the symbolic names for the keys.  (This
change is largely transparent to the user, since define-key and lookup-key
still work in emacs18 compatible ways.)  If your keyboard generates a
character, you can bind a command to it, whether that character has an ASCII
equivalent or not.  Meta-x and oslash are distinct; Meta-oslash is also
distinct.

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

(PS: Lucid Emacs 19.2 -- labrea.stanford.edu: pub/gnu/lucid/)