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

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

[Eli Zaretskii]

tabulated-list-init-header assumes without testing that u+25b2 and
u+25bc will be displayed as themselves.  But with various values of
glyphless-char-display-control, this may not be true.  Also, on text
terminals these characters generally cannot be displayed, which makes
the entire header line ugly, if not bug-like.

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

[Eli Zaretskii]

tabulated-list-init-header assumes without testing that u+25b2 and
u+25bc will be displayed as themselves.  But with various values of
glyphless-char-display-control, this may not be true.  Also, on text
terminals these characters generally cannot be displayed, which makes
the entire header line ugly, if not bug-like.

I'm not sure how to resolve this for text terminals.  Perhaps we
simply should not display these characters then.

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> tabulated-list-init-header assumes without testing that u+25b2 and
> u+25bc will be displayed as themselves.  But with various values of
> glyphless-char-display-control, this may not be true.  Also, on text
> terminals these characters generally cannot be displayed, which makes
> the entire header line ugly, if not bug-like.

We can probably use "^" and "v" when the unicode glyphs cannot be
displayed, but it sure would be nice to the glyphs whereever possible.
Any idea how to go about checking this?

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 08 Apr 2011 14:27:37 -0400
> 
> We can probably use "^" and "v" when the unicode glyphs cannot be
> displayed, but it sure would be nice to the glyphs whereever possible.
> Any idea how to go about checking this?

I think you will find glyphless-char-display (which is a char-table)
useful.

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

[Eli Zaretskii]

> Date: Fri, 08 Apr 2011 21:47:29 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Chong Yidong <cyd@stupidchicken.com>
> > Cc: emacs-devel@gnu.org
> > Date: Fri, 08 Apr 2011 14:27:37 -0400
> > 
> > We can probably use "^" and "v" when the unicode glyphs cannot be
> > displayed, but it sure would be nice to the glyphs whereever possible.
> > Any idea how to go about checking this?
> 
> I think you will find glyphless-char-display (which is a char-table)
> useful.

Also this:

  (unencodable-char-position 0 1 
                             (terminal-coding-system) 
                             nil (string CHARACTER))

will tell you whether CHARACTER can be safely encoded for the selected
frame's terminal.

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

[Štěpán Němec]

Eli Zaretskii <eliz@gnu.org> writes:

> tabulated-list-init-header assumes without testing that u+25b2 and
> u+25bc will be displayed as themselves.  But with various values of
> glyphless-char-display-control, this may not be true.  Also, on text
> terminals these characters generally cannot be displayed, which makes
                             ^^^^^^^^^
I wonder what your meant by this word? Both characters display fine for
me in urxvt and xterm, and even in the linux console (displayed as
up/down arrows instead of triangles) on a Debian system. Just a data
point.

  Štěpán

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

[Eli Zaretskii]

> From: Štěpán Němec <stepnem@gmail.com>
> Cc: Chong Yidong <cyd@stupidchicken.com>,  emacs-devel@gnu.org
> Date: Sat, 09 Apr 2011 12:26:42 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > tabulated-list-init-header assumes without testing that u+25b2 and
> > u+25bc will be displayed as themselves.  But with various values of
> > glyphless-char-display-control, this may not be true.  Also, on text
> > terminals these characters generally cannot be displayed, which makes
>                              ^^^^^^^^^
> I wonder what your meant by this word?

"Generally" as in "for any terminal encoding but one".

> Both characters display fine for me in urxvt and xterm, and even in
> the linux console (displayed as up/down arrows instead of triangles)
> on a Debian system. Just a data point.

That's exactly the _only_ terminal encoding where these characters can
be displayed correctly, and even then assuming that the terminal can
display them.  Displaying them as an up and down arrow is just an
emulation (and not a faithful one at that, in this case, if you ask
me).

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

[Stefan Monnier]

>> Both characters display fine for me in urxvt and xterm, and even in
>> the linux console (displayed as up/down arrows instead of triangles)
>> on a Debian system. Just a data point.
> That's exactly the _only_ terminal encoding where these characters can

Still, that covers pretty much *all* terminals under GNU/Linux systems.
And IIUC the same holds for Mac OS X terminals, so the only significant
counter example is the Windows terminals (does putty support/encourage
utf-8?).
But your point still holds true: we want/need to properly handle the
case where the terminal cannot display those chars.  I think that
glyphless-char-display-control sounds like a good way to attack
the problem.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Štěpán Němec <stepnem@gmail.com>,
>   cyd@stupidchicken.com,  emacs-devel@gnu.org
> Date: Sat, 09 Apr 2011 10:56:27 -0300
> 
> >> Both characters display fine for me in urxvt and xterm, and even in
> >> the linux console (displayed as up/down arrows instead of triangles)
> >> on a Debian system. Just a data point.
> > That's exactly the _only_ terminal encoding where these characters can
> 
> Still, that covers pretty much *all* terminals under GNU/Linux systems.

The world is not limited to GNU/Linux, and even GNU/Linux users might
prefer non-UTF-8 encoding.

> And IIUC the same holds for Mac OS X terminals, so the only significant
> counter example is the Windows terminals (does putty support/encourage
> utf-8?).

Yes PuTTY does support UTF-8.  I don't know how to measure
"encourage"; it's not the default, if that's what you are asking.  The
default is the current system codepage, which is never UTF-8 on
Windows.

> But your point still holds true: we want/need to properly handle the
> case where the terminal cannot display those chars.

Which is why I don't understand Štěpán's remark at all.  It sounded
like he was saying this isn't a problem because it works on GNU/Linux
terminals that use UTF-8.

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Chong Yidong <cyd@stupidchicken.com>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 08 Apr 2011 14:27:37 -0400
>> 
>> We can probably use "^" and "v" when the unicode glyphs cannot be
>> displayed, but it sure would be nice to the glyphs whereever possible.
>> Any idea how to go about checking this?
>
> I think you will find glyphless-char-display (which is a char-table)
> useful.

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.

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.
Thoughts?


*** src/xdisp.c	2011-04-09 16:35:19 +0000
--- src/xdisp.c	2011-04-09 19:18:08 +0000
***************
*** 736,741 ****
--- 736,742 ----
  
  /* Symbol for the purpose of Vglyphless_char_display.  */
  Lisp_Object Qglyphless_char_display;
+ Lisp_Object Qglyphless_char_display_default;
  
  /* Method symbols for Vglyphless_char_display.  */
  static Lisp_Object Qhex_code, Qempty_box, Qthin_space, Qzero_width;
***************
*** 5579,5587 ****
  Lisp_Object
  lookup_glyphless_char_display (int c, struct it *it)
  {
!   Lisp_Object glyphless_method = Qnil;
  
!   if (CHAR_TABLE_P (Vglyphless_char_display)
        && CHAR_TABLE_EXTRA_SLOTS (XCHAR_TABLE (Vglyphless_char_display)) >= 1)
      glyphless_method = (c >= 0
  			? CHAR_TABLE_REF (Vglyphless_char_display, c)
--- 5580,5592 ----
  Lisp_Object
  lookup_glyphless_char_display (int c, struct it *it)
  {
!   Lisp_Object glyphless_method
!     = (c < 0)
!     ? get_it_property (it, Qglyphless_char_display_default)
!     : Qnil;
  
!   if (NILP (glyphless_method)
!       && CHAR_TABLE_P (Vglyphless_char_display)
        && CHAR_TABLE_EXTRA_SLOTS (XCHAR_TABLE (Vglyphless_char_display)) >= 1)
      glyphless_method = (c >= 0
  			? CHAR_TABLE_REF (Vglyphless_char_display, c)
***************
*** 26974,26979 ****
--- 26979,26986 ----
    Qchar_table_extra_slots = intern_c_string ("char-table-extra-slots");
    Fput (Qglyphless_char_display, Qchar_table_extra_slots, make_number (1));
  
+   DEFSYM (Qglyphless_char_display_default, "glyphless-char-display-default");
+ 
    DEFVAR_LISP ("glyphless-char-display", Vglyphless_char_display,
  	       doc: /* Char-table to control displaying of glyphless characters.
  Each element, if non-nil, is an ASCII acronym string (displayed in a box)
*** lisp/emacs-lisp/tabulated-list.el	2011-04-06 21:55:08 +0000
--- lisp/emacs-lisp/tabulated-list.el	2011-04-09 19:23:20 +0000
***************
*** 143,148 ****
--- 143,154 ----
      map)
    "Local keymap for `tabulated-list-mode' sort buttons.")
  
+ (defvar tabulated-list-up-arrow
+   (propertize "▲" 'glyphless-char-display-default 'thin-space))
+ 
+ (defvar tabulated-list-down-arrow
+   (propertize "▼" 'glyphless-char-display-default 'thin-space))
+ 
  (defun tabulated-list-init-header ()
    "Set up header line for the Tabulated List buffer."
    (let ((x tabulated-list-padding)
***************
*** 167,179 ****
  	  ;; The selected sort column
  	  ((equal (car col) (car tabulated-list-sort-key))
  	   (apply 'propertize
! 		  (concat label
! 			  (cond
! 			   ((> (+ 2 (length label)) width)
! 			    "")
! 			   ((cdr tabulated-list-sort-key)
! 			    " ▲")
! 			   (t " ▼")))
  		  'face 'bold
  		  'tabulated-list-column-name (car col)
  		  button-props))
--- 173,185 ----
  	  ;; The selected sort column
  	  ((equal (car col) (car tabulated-list-sort-key))
  	   (apply 'propertize
! 		  (cond
! 		   ((> (+ 2 (length label)) width)
! 		    label)
! 		   ((cdr tabulated-list-sort-key)
! 		    (concat label " " tabulated-list-up-arrow))
! 		   (t
! 		    (concat label " " tabulated-list-down-arrow)))
  		  'face 'bold
  		  'tabulated-list-column-name (car col)
  		  button-props))

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

[Stefan Monnier]

> 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?

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


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> 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.

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

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

That's apparently not how glyphless-char-display works.  The docstring
is a bit ambiguous, but glyphless-char-display actually *defines* the
characters that cannot be displayed in an ordinary way.  For instance,
if you do (aset glyphless-char-display ?a 'empty-box), that tells Emacs
that "a" is a glyphless character, and causes all "a"'s to be displayed
as empty boxes.

What you are thinking of is a char table that says "how should we
display character C if it has no font", but AFAICT there is currently no
such facility.  There is only the extra slot of glyphless-char-display,
which handles all characters with no font without discriminating.

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Sun, 10 Apr 2011 11:47:58 -0400
> 
> > 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".
> 
> That's apparently not how glyphless-char-display works.  The docstring
> is a bit ambiguous, but glyphless-char-display actually *defines* the
> characters that cannot be displayed in an ordinary way.

Yes.

> For instance,
> if you do (aset glyphless-char-display ?a 'empty-box), that tells Emacs
> that "a" is a glyphless character, and causes all "a"'s to be displayed
> as empty boxes.

That's right, but why would you do something like that with a
characters that is perfectly displayable?  You should only do that
with characters that cannot be displayed, like unencodable characters
on a tty.  That's what I was trying to convey; sorry if I failed to
get that across.

> What you are thinking of is a char table that says "how should we
> display character C if it has no font", but AFAICT there is currently no
> such facility.

glyphless-char-display is such a facility, but it is not automatic, it
needs too be filled with appropriate values.  At least the fact that a
character cannot be displayed normally is determined automatically.

Btw, I'm not sure how all this is related to the issue at hand.

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> For instance, if you do (aset glyphless-char-display ?a 'empty-box),
>> that tells Emacs that "a" is a glyphless character, and causes all
>> "a"'s to be displayed as empty boxes.
>
> That's right, but why would you do something like that with a
> characters that is perfectly displayable?  You should only do that
> with characters that cannot be displayed, like unencodable characters
> on a tty.  That's what I was trying to convey; sorry if I failed to
> get that across.

I think what you have in mind (correct me if I'm wrong) is to do some
kind of terminal detection, and then conditionally set up the
glyphless-char-display char table in the tabulated-list buffer.  That
solution is not satisfactory, because it won't work in the multi-tty
case.  The same buffer might be simultaneously displayed on a text
terminal and on X, and we want the X display to work properly.

The correct fix is to provide some way to say "in the no-font case,
display this character in this way".  There's currently no multi-tty
compatible way to do this for one specific character.

An alternative to my earlier text-property-based proposal is to extend
glyphless-char-display's extra slot, so that in addition to the symbols
`hex-code' and `empty-box', it can hold yet another char table for
resolving the display of individual fontless characters.

However, this has the undesireable (though minor) side-effect of
changing display in the main part of the buffer, so I still prefer the
text-property-based solution.

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Date: Sun, 10 Apr 2011 14:11:31 -0400
> 
> I think what you have in mind (correct me if I'm wrong) is to do some
> kind of terminal detection, and then conditionally set up the
> glyphless-char-display char table in the tabulated-list buffer.

No, I was trying to suggest something much simpler: see if these
characters can be displayed, e.g. with unencodable-char-position (and
something similar for GUI sessions), and if so, use surrogates
directly in the code, without going through glyphless-char-display.

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think what you have in mind (correct me if I'm wrong) is to do some
>> kind of terminal detection, and then conditionally set up the
>> glyphless-char-display char table in the tabulated-list buffer.
>
> No, I was trying to suggest something much simpler: see if these
> characters can be displayed, e.g. with unencodable-char-position (and
> something similar for GUI sessions), and if so, use surrogates
> directly in the code, without going through glyphless-char-display.

How would this handle the multi-tty case?

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Date: Mon, 11 Apr 2011 13:31:41 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, I was trying to suggest something much simpler: see if these
> > characters can be displayed, e.g. with unencodable-char-position (and
> > something similar for GUI sessions), and if so, use surrogates
> > directly in the code, without going through glyphless-char-display.
> 
> How would this handle the multi-tty case?

The only thing that matters on a tty is its encoding, which you pass
to unencodable-char-position.

If you mean that some frames can be GUI frames, then you can always
know what kind of frame is the selected one, right?

Or are you thinking about something else?

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> > No, I was trying to suggest something much simpler: see if these
>> > characters can be displayed, e.g. with unencodable-char-position (and
>> > something similar for GUI sessions), and if so, use surrogates
>> > directly in the code, without going through glyphless-char-display.
>>
>> How would this handle the multi-tty case?
>
> The only thing that matters on a tty is its encoding, which you pass
> to unencodable-char-position.
>
> If you mean that some frames can be GUI frames, then you can always
> know what kind of frame is the selected one, right?
>
> Or are you thinking about something else?

Suppose we make the *Process List* buffer and display it in a GUI
terminal.  Then, we create a text terminal in the same Emacs session,
and display that same buffer in the text terminal.

The buffer has to display correctly, without a priori knowledge of the
terminal(s) on which it is to be displayed.

Therefore, checking unencodable-char-position at buffer creation time
does not work.  The fallback behavior has to be done at redisplay time.

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Date: Mon, 11 Apr 2011 14:39:15 -0400
> 
> Suppose we make the *Process List* buffer and display it in a GUI
> terminal.  Then, we create a text terminal in the same Emacs session,
> and display that same buffer in the text terminal.
> 
> The buffer has to display correctly, without a priori knowledge of the
> terminal(s) on which it is to be displayed.
> 
> Therefore, checking unencodable-char-position at buffer creation time
> does not work.  The fallback behavior has to be done at redisplay time.

So we are going to invent a new display feature, just to display 2
fancy characters in a specialized mode buffer, and in a way that will
support simultaneous display in several different display types?  I'd
say it's an overkill.  Perhaps we should simply compromise and use
ASCII art, or no indication at all.

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> So we are going to invent a new display feature, just to display 2
> fancy characters in a specialized mode buffer, and in a way that will
> support simultaneous display in several different display types?

Yep.

> I'd say it's an overkill.  Perhaps we should simply compromise and use
> ASCII art, or no indication at all.

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

┌─┬─┐
│a│b│
├─┼─┤
│ │ │
└─┴─┘

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

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

[Stefan Monnier]

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

Agreed.  cvs-status has suffered from this problem since its creation,
and this problem is the main reason why list-buffers doesn't have such
little arrows to indicate the sorting order (I wrote some code for it
but could never convince myself to install it because of this problem).


        Stefan

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Mon, 11 Apr 2011 18:31:51 -0400
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So we are going to invent a new display feature, just to display 2
> > fancy characters in a specialized mode buffer, and in a way that will
> > support simultaneous display in several different display types?
> 
> Yep.
> 
> > I'd say it's an overkill.  Perhaps we should simply compromise and use
> > ASCII art, or no indication at all.
> 
> 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
> 
> ┌─┬─┐
> │a│b│
> ├─┼─┤
> │ │ │
> └─┴─┘
> 
> on graphical terminals, using the Unicode box-drawing glyphs, and
> displays the equivalent ASCII borders on terminals that don't handle
> Unicode.

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.

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.

WDYT?

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

[Kevin Rodgers]

On 4/11/11 10:51 PM, Eli Zaretskii wrote:
>> From: Chong Yidong<cyd@stupidchicken.com>
>> Date: Mon, 11 Apr 2011 18:31:51 -0400
>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
>>
...
>> 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
>>
>> ┌─┬─┐
>> │a│b│
>> ├─┼─┤
>> │ │ │
>> └─┴─┘
>>
>> on graphical terminals, using the Unicode box-drawing glyphs, and
>> displays the equivalent ASCII borders on terminals that don't handle
>> Unicode.
>
> 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

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

[Eli Zaretskii]

> From: Kevin Rodgers <kevin.d.rodgers@gmail.com>
> 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.

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

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

> 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.
>
> 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.
>
> WDYT?

Instead of changing the meaning of glyphless-char-display, it might be
better to use a new char-table---say, fallback-display-table, by analogy
with buffer-display-table.

OTOH, it's also more complicated to implement than the text-property
idea; the mapping must be done somewhere in get_next_display_element,
just after we determine the font to use for a multibyte character,
compared to just adding a few lines to x_produce_glyphs.  But I agree
that it's probably a cleaner system.  I'll look into it.

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

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Date: Tue, 12 Apr 2011 12:12:09 -0400
> 
> Instead of changing the meaning of glyphless-char-display, it might be
> better to use a new char-table---say, fallback-display-table, by analogy
> with buffer-display-table.

I don't think using a display table is a good idea, because the
display engine handles display tables in quite a different way from
the glyphless-char-display support, and on a very different level.

> OTOH, it's also more complicated to implement than the text-property
> idea; the mapping must be done somewhere in get_next_display_element,
> just after we determine the font to use for a multibyte character,
> compared to just adding a few lines to x_produce_glyphs.  But I agree
> that it's probably a cleaner system.  I'll look into it.

Thanks.