* tabulated-list-init-header and glyphless-char-display
@ 2011-04-08 17:17 Eli Zaretskii
2011-04-08 18:27 ` Chong Yidong
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2011-04-08 17:17 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* tabulated-list-init-header and glyphless-char-display
@ 2011-04-08 17:26 Eli Zaretskii
2011-04-09 10:26 ` Štěpán Němec
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2011-04-08 17:26 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-08 17:17 tabulated-list-init-header and glyphless-char-display Eli Zaretskii
@ 2011-04-08 18:27 ` Chong Yidong
2011-04-08 18:47 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Chong Yidong @ 2011-04-08 18:27 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-08 18:27 ` Chong Yidong
@ 2011-04-08 18:47 ` Eli Zaretskii
2011-04-08 18:59 ` Eli Zaretskii
2011-04-09 19:26 ` Chong Yidong
0 siblings, 2 replies; 27+ messages in thread
From: Eli Zaretskii @ 2011-04-08 18:47 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-08 18:47 ` Eli Zaretskii
@ 2011-04-08 18:59 ` Eli Zaretskii
2011-04-09 19:26 ` Chong Yidong
1 sibling, 0 replies; 27+ messages in thread
From: Eli Zaretskii @ 2011-04-08 18:59 UTC (permalink / raw
To: cyd, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-08 17:26 Eli Zaretskii
@ 2011-04-09 10:26 ` Štěpán Němec
2011-04-09 12:12 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Štěpán Němec @ 2011-04-09 10:26 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Chong Yidong, emacs-devel
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-09 10:26 ` Štěpán Němec
@ 2011-04-09 12:12 ` Eli Zaretskii
2011-04-09 13:56 ` Stefan Monnier
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2011-04-09 12:12 UTC (permalink / raw
To: Štěpán Němec; +Cc: cyd, emacs-devel
> 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).
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-09 12:12 ` Eli Zaretskii
@ 2011-04-09 13:56 ` Stefan Monnier
2011-04-09 15:37 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2011-04-09 13:56 UTC (permalink / raw
To: Eli Zaretskii; +Cc: cyd, Štěpán Němec, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-09 13:56 ` Stefan Monnier
@ 2011-04-09 15:37 ` Eli Zaretskii
0 siblings, 0 replies; 27+ messages in thread
From: Eli Zaretskii @ 2011-04-09 15:37 UTC (permalink / raw
To: Stefan Monnier; +Cc: cyd, stepnem, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-08 18:47 ` Eli Zaretskii
2011-04-08 18:59 ` Eli Zaretskii
@ 2011-04-09 19:26 ` Chong Yidong
2011-04-10 3:59 ` Stefan Monnier
1 sibling, 1 reply; 27+ messages in thread
From: Chong Yidong @ 2011-04-09 19:26 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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))
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-09 19:26 ` Chong Yidong
@ 2011-04-10 3:59 ` Stefan Monnier
2011-04-10 5:24 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2011-04-10 3:59 UTC (permalink / raw
To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-10 3:59 ` Stefan Monnier
@ 2011-04-10 5:24 ` Eli Zaretskii
2011-04-10 15:47 ` Chong Yidong
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2011-04-10 5:24 UTC (permalink / raw
To: Stefan Monnier; +Cc: cyd, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-10 5:24 ` Eli Zaretskii
@ 2011-04-10 15:47 ` Chong Yidong
2011-04-10 16:53 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Chong Yidong @ 2011-04-10 15:47 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-10 15:47 ` Chong Yidong
@ 2011-04-10 16:53 ` Eli Zaretskii
2011-04-10 18:11 ` Chong Yidong
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2011-04-10 16:53 UTC (permalink / raw
To: Chong Yidong; +Cc: monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-10 16:53 ` Eli Zaretskii
@ 2011-04-10 18:11 ` Chong Yidong
2011-04-11 17:03 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Chong Yidong @ 2011-04-10 18:11 UTC (permalink / raw
To: Eli Zaretskii; +Cc: monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-10 18:11 ` Chong Yidong
@ 2011-04-11 17:03 ` Eli Zaretskii
2011-04-11 17:31 ` Chong Yidong
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2011-04-11 17:03 UTC (permalink / raw
To: Chong Yidong; +Cc: monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-11 17:03 ` Eli Zaretskii
@ 2011-04-11 17:31 ` Chong Yidong
2011-04-11 18:04 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Chong Yidong @ 2011-04-11 17:31 UTC (permalink / raw
To: Eli Zaretskii; +Cc: monnier, emacs-devel
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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-11 17:31 ` Chong Yidong
@ 2011-04-11 18:04 ` Eli Zaretskii
2011-04-11 18:39 ` Chong Yidong
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2011-04-11 18:04 UTC (permalink / raw
To: Chong Yidong; +Cc: monnier, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-11 18:04 ` Eli Zaretskii
@ 2011-04-11 18:39 ` Chong Yidong
2011-04-11 19:27 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Chong Yidong @ 2011-04-11 18:39 UTC (permalink / raw
To: Eli Zaretskii; +Cc: monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-11 18:39 ` Chong Yidong
@ 2011-04-11 19:27 ` Eli Zaretskii
2011-04-11 22:31 ` Chong Yidong
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2011-04-11 19:27 UTC (permalink / raw
To: Chong Yidong; +Cc: monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-11 19:27 ` Eli Zaretskii
@ 2011-04-11 22:31 ` Chong Yidong
2011-04-12 3:57 ` Stefan Monnier
2011-04-12 4:51 ` Eli Zaretskii
0 siblings, 2 replies; 27+ messages in thread
From: Chong Yidong @ 2011-04-11 22:31 UTC (permalink / raw
To: Eli Zaretskii; +Cc: monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-11 22:31 ` Chong Yidong
@ 2011-04-12 3:57 ` Stefan Monnier
2011-04-12 4:51 ` Eli Zaretskii
1 sibling, 0 replies; 27+ messages in thread
From: Stefan Monnier @ 2011-04-12 3:57 UTC (permalink / raw
To: Chong Yidong; +Cc: Eli Zaretskii, emacs-devel
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-11 22:31 ` Chong Yidong
2011-04-12 3:57 ` Stefan Monnier
@ 2011-04-12 4:51 ` Eli Zaretskii
2011-04-12 5:42 ` Kevin Rodgers
2011-04-12 16:12 ` Chong Yidong
1 sibling, 2 replies; 27+ messages in thread
From: Eli Zaretskii @ 2011-04-12 4:51 UTC (permalink / raw
To: Chong Yidong; +Cc: monnier, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-12 4:51 ` Eli Zaretskii
@ 2011-04-12 5:42 ` Kevin Rodgers
2011-04-12 5:58 ` Eli Zaretskii
2011-04-12 16:12 ` Chong Yidong
1 sibling, 1 reply; 27+ messages in thread
From: Kevin Rodgers @ 2011-04-12 5:42 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-12 5:42 ` Kevin Rodgers
@ 2011-04-12 5:58 ` Eli Zaretskii
0 siblings, 0 replies; 27+ messages in thread
From: Eli Zaretskii @ 2011-04-12 5:58 UTC (permalink / raw
To: Kevin Rodgers; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-12 4:51 ` Eli Zaretskii
2011-04-12 5:42 ` Kevin Rodgers
@ 2011-04-12 16:12 ` Chong Yidong
2011-04-12 16:45 ` Eli Zaretskii
1 sibling, 1 reply; 27+ messages in thread
From: Chong Yidong @ 2011-04-12 16:12 UTC (permalink / raw
To: Eli Zaretskii; +Cc: monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: tabulated-list-init-header and glyphless-char-display
2011-04-12 16:12 ` Chong Yidong
@ 2011-04-12 16:45 ` Eli Zaretskii
0 siblings, 0 replies; 27+ messages in thread
From: Eli Zaretskii @ 2011-04-12 16:45 UTC (permalink / raw
To: Chong Yidong; +Cc: monnier, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2011-04-12 16:45 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-08 17:17 tabulated-list-init-header and glyphless-char-display Eli Zaretskii
2011-04-08 18:27 ` Chong Yidong
2011-04-08 18:47 ` Eli Zaretskii
2011-04-08 18:59 ` Eli Zaretskii
2011-04-09 19:26 ` Chong Yidong
2011-04-10 3:59 ` Stefan Monnier
2011-04-10 5:24 ` Eli Zaretskii
2011-04-10 15:47 ` Chong Yidong
2011-04-10 16:53 ` Eli Zaretskii
2011-04-10 18:11 ` Chong Yidong
2011-04-11 17:03 ` Eli Zaretskii
2011-04-11 17:31 ` Chong Yidong
2011-04-11 18:04 ` Eli Zaretskii
2011-04-11 18:39 ` Chong Yidong
2011-04-11 19:27 ` Eli Zaretskii
2011-04-11 22:31 ` Chong Yidong
2011-04-12 3:57 ` Stefan Monnier
2011-04-12 4:51 ` Eli Zaretskii
2011-04-12 5:42 ` Kevin Rodgers
2011-04-12 5:58 ` Eli Zaretskii
2011-04-12 16:12 ` Chong Yidong
2011-04-12 16:45 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2011-04-08 17:26 Eli Zaretskii
2011-04-09 10:26 ` Štěpán Němec
2011-04-09 12:12 ` Eli Zaretskii
2011-04-09 13:56 ` Stefan Monnier
2011-04-09 15:37 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).