[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: Kevin Rodgers
Subject: Re: tabulated-list-init-header and glyphless-char-display
Date: Mon, 11 Apr 2011 23:42:53 -0600
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv: Gecko/20110303 Thunderbird/3.1.9

On 4/11/11 10:51 PM, Eli Zaretskii wrote:
From: Chong Yidong<address@hidden>
Date: Mon, 11 Apr 2011 18:31:51 -0400
Cc: address@hidden, address@hidden

I suspect there will be other situations where it's convenient to use
unicode glyphs in Emacs buffers.  If we can design a sufficiently
flexible system, I think this is a good investment.

For example, one could imagine a version of table.el that displays

│ │ │

on graphical terminals, using the Unicode box-drawing glyphs, and
displays the equivalent ASCII borders on terminals that don't handle

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).

I think this is better than the text property suggestion, because
glyphless-char-display can be set once and by default, whereas with
text properties each Lisp application that needs it will have to do
that manually.

Kevin Rodgers
Denver, Colorado, USA

reply via email to

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