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