Re: Possible change to startup.el

[David Kastrup <dak@gnu.org>]

[proposal was IIRC:]

(menu-string-displayable-p STRING &optional DISPLAY)

Richard Stallman <rms@gnu.org> writes:

>     For example, AUCTeX has an option that will enable the use of Unicode
>     math characters in menus.  How can I know when to enable it by
>     default?  I need to know for every platform that Emacs might be
>     running on, and this might even depend on your settings for the menu
>     font and the locale.
>
> The interface that has been proposed is defined so as to make
> complete informatoin available about what is or isn't supported.
> That makes it so complex to implement--to complex to be considered
> for now, and undesirable even for later.

I can't quite see why having complete information about what is or
isn't supported would be undesirable for later.  As an application
developer, I'd rather consider it desirable.  It seems reasonable to
solve this task once, within Emacs.

> AUCTeX needs *some* information.  Could it be satisfied with less?
> What is the minimum, simplest, information that could be enough?

Well, we can omit the "technicality" of actually installed fonts: it
would be sufficient to know whether a given string could be mapped to
the toolkit _if_ the fonts were available (this will be an incentive
to people to actually install fonts _if_ they could be made to work).
I can't see how one could get along with different call semantics,
though: different displays may have different toolkits at least on the
upcoming multi-tty (like being on the tty and on x11), so it would
seem silly not to provide the DISPLAY option, and the various unifying
modes mean that we can't really give a definite decision when only
knowing about the charset instead of the actual characters in STRING.

As an intermediate version, something based on the charset/display
combination instead of the character/display combination would help a
lot already, and since charsets are not strings, one could later make
the function accept a string, too, or just a single character (in
Emacs encoding?).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum