RE: Key bindings proposal

[Drew Adams]

> That basically implies that it has to be part of the text (and not as
> a text-property).  So the scheme using an underscore or some such char
> seems to be the way to go.
> I see two questions left open:
> 1- which char to use (I'd favor _ since it's what's used in the Free
>    toolkit I happen to know).
> 2- how to deal with breaking backward compatibility (e.g. menus which
>    currently include _).

Not really to weigh in here. And I have not been following this with much
attention or interest...

Just a reminder that dynamically generated menus can contain nearly anything. A
buffer name used as a menu item could easily contain `_', as could a function,
class, etc. name used as an Imenu menu item.  Always treating `_' in a name as
an accelerator indicator would be quite limiting and bug-/error-prone, I expect.

Typically for this kind of thing (treating a char as special sometimes but not
always) some char escaping/unescaping mechanism is used.

Jan D. mentioned that `_' could escape an underscore (it does in Gtk+) so that
`__' (2 of them) inhibits acting as an accelerator indication.  But then there
needs to be an unambigous way to specify an underscore itself as an accelerator
char.  Perhaps `___' (3 or them) could (be made to) do that.  How does Gtk+ deal
with this?  In any case, this stuff needs to be well thought out before going
ahead.

I'm glad (and surprised) to see that you are concerned about backward
compatibility here. ;-)  I doubt there is a good way to respect that, however,
if the menu-item text itself is changed.  (But I also agree about the
limitations of using a text property instead of a char.)

If a menu item contains an underscore and there was no intention of indicating
an accelerator, then there is little or nothing to be done - modulo some way to
test the intention (e.g. version of the code that creates the menu item).  I see
no good way to both (a) respect `_' in old code as _not_ meaning anything
special and (b) make `_' (together with an appropriate escape feature) indicate
an accelerator.

3rd-party code will just have to adjust, providing two sets of menu items: one
that works in old Emacs versions (no accelerator indication) and one that works
in new versions.  Ugh.  And code that dynamically generates menu items would
need to be adapted to always DTRT.  Ugh.

It is also true that introducing a new keyword would complicate code that parses
menu items (or keymaps generally).