RE: Simple Tasks, new TODO category

[Stephen J. Turnbull]

Drew Adams writes:

 > Sorry to chime in once more, but I again get the impression that
 > you are speaking about giving a special interpretation to a
 > displayable character that might appear in a menu item, and that
 > you are trying to find a character or string that is "less likely
 > to be used in a menu item name".
 > 
 > If so, that's a mistake.

Well, why don't we contribute some experience to this excessively
theoretical discussion.

Specifically, it works in practice, since 1997, with no complaints I
can recall.  The logic for use of "%_" is that it looks like a printf
format operator, and does what it looks like: underlines the following
character in the string.  Because of the ubiquity of printf format
strings, programmers are used to treating strings containing "%"
specially.  It is very easy to see the accelerators in menu code that
uses them.  Besides the "%_" sequence, the "%%" sequence is treated
specially; it resolves to a single "%".

XEmacs also provides the notation :accelerator ?A in menu items, but
this is ambiguous for many strings.  I give an example below where you
may want the fine control.

 > Please don't make any assumptions

XEmacs doesn't.  We simply ask that programmer respect the API, which
provides a means to display anything they want.  If you want to
construct a menu from "naively" generated input, simply run each
string through a filter that doubles all "%" before inserting it in
the appropriate menu item.

 > about which (displayable) characters

This is Emacs; *all* characters are displayable.

 > might be used in a menu item. Such assumptions are naive or
 > misguided. Find some other mechanism; don't rely on people not
 > including some particular character (or string) in item names. 

Other mechanisms have the problem that they are unfriendly to anything
that analyzes menu strings to find out what their semantics are.  I18N
has already been pointed out; help is another such application.  It is
not sufficient to indicate the character to use; I recall one menu
which looked something like (accelerators are uppercase)

before    after

Bcde      Bcde
bGhi      fGhi
Ajak      ajAk
amnO      lmnO

and it was perceptibly easier to use with the accelerators all lined
up on the diagonal.  Indicating the position is bug-prone; it's easy
to imagine that changing the menu string without updating the position
flag could result in collisions.  Counting positions is also tedious,
not to mention ambiguous if you have East Asian character sets (are
you counting columns, where each ideograph character counts for two
columns, or characters?)  Of course you can deal with these issues,
but since all the methods have the same result for endusers when
applied correctly, why not use the method that is least bug-prone for
99% or more of menu strings in use, which also has a simple and
commonly used escaping mechanism?