Re: tabulated-list-init-header and glyphless-char-display

[Eli Zaretskii]

> From: Kevin Rodgers <address@hidden>
> Date: Mon, 11 Apr 2011 23:42:53 -0600
> 
> > Then let's extend glyphless-char-display to provide this information.
> > That is, for each character, it should provide display information
> > both for GUI and for text-mode displays.  It can do that by providing
> > an option to have an element of the char-table be a vector of 2
> > elements, instead of just one value today.  Most table entries will
> > still be symbols like today, but we could have some of them be
> > vectors, as in this case and in the case of line-drawing characters.
> 
> Rather than returning 2 values, the optional argument could be FRAME to
> indicate whether the caller needs that information for a graphic
> vs. terminal frame (nil would means the current frame of course).

Looking at a frame does not yet give the crucial information of what
to display instead of the character if the frame cannot handle it.
OTOH, determining that the frame cannot handle it is trivial.  So with
your suggestion, the information needed by the display engine will not
be available, which makes this kind of entry useless.

What I meant is to have a possibility to put in the char-table an
element of the form

  [GUI-DISPLAY TTY-DISPLAY]

where each one of the elements could be either one of the methods we
use today (`hex-code', `empty-box', etc.; see
glyphless-char-display-control), or a codepoint of a character (or
maybe even a string) to display.