[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: tabulated-list-init-header and glyphless-char-display
Date: Sun, 10 Apr 2011 01:24:41 -0400

> From: Stefan Monnier <address@hidden>
> Cc: Eli Zaretskii <address@hidden>,  address@hidden
> Date: Sun, 10 Apr 2011 00:59:21 -0300
> > Thanks.  This doesn't quite do what I want, because (i) it applies to
> > the entire buffer, when I only want it to apply to one particular glyph,
> > and (ii) the char table's "fallback display" slot applies to all glyphs
> > with no fonts, when I only want to handle two particular glyphs.
> Hmm... so IIUC we distinguish between "glyphless" and "without a font".
> Where do we explain the difference between the two, and is there a good
> reason to distinguish the two cases?

No, "glyphless" and "without a font" are (and should be) synonyms.
Except that on a text terminal, "without a font" means "cannot be
encoded for the current terminal encoding".

> > I propose introducing a `glyphless-char-display-default' text-property,
> > which, if non-nil, overrides glyphless-char-display's "fallback display"
> > slot locally.  See attached patch, which seems to do the right thing.
> I think problem (i) above is not a real problem, so if we can fix (ii)
> by changing glyphless-char-display we wouldn't need such a text property.

What I had in mind was something much more lightweight: look at these
characters' cells in glyphless-char-display (or use
unencodable-char-position on a tty), and if that indicates that the
characters cannot be displayed, use the surrogates.  I see no need for
a more general infrastructure for this case, as it is quite rare.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]