* face vs. mouse-face text property @ 2012-01-18 21:34 Michael Heerdegen 2012-01-19 7:20 ` Chong Yidong 2012-01-19 12:19 ` Eli Zaretskii 0 siblings, 2 replies; 21+ messages in thread From: Michael Heerdegen @ 2012-01-18 21:34 UTC (permalink / raw) To: Emacs Development Hello, I recognized that the area highlighted when using a mouse-face is different from that when using the face text property when the propertized string includes newlines. For example, try that: (with-current-buffer (generate-new-buffer "test") (pop-to-buffer (current-buffer)) (let ((o1 (make-overlay (point) (progn (insert "\n\n") (point))))) (overlay-put o1 'face 'highlight)) (insert "\n--\n") (let ((o2 (make-overlay (point) (progn (insert "\n\n") (point))))) (overlay-put o2 'mouse-face 'highlight))) While the first overlay is visible, you see nothing at all when you move the mouse over the second overlay. If you try this: (with-current-buffer (generate-new-buffer "test") (pop-to-buffer (current-buffer)) (let ((o1 (make-overlay (point) (progn (insert "\ntext\n") (point))))) (overlay-put o1 'face 'highlight)) (insert "\n--\n") (let ((o2 (make-overlay (point) (progn (insert "\ntext\n") (point))))) (overlay-put o2 'mouse-face 'highlight))) the first newline in the second overlay gets highlighted when you move the mouse over it, but not the second newline char. My question is: is this a bug, or intended behavior? If it is intended, why, and is there a way to get the mouse highlighting nevertheless work or to override the default behavior? In my scenario, it is important that the mouse-face works also for strings consisting of newlines, to indicate that it's clickable text. Thanks, Michael. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-18 21:34 face vs. mouse-face text property Michael Heerdegen @ 2012-01-19 7:20 ` Chong Yidong 2012-01-19 12:19 ` Eli Zaretskii 1 sibling, 0 replies; 21+ messages in thread From: Chong Yidong @ 2012-01-19 7:20 UTC (permalink / raw) To: emacs-devel; +Cc: michael_heerdegen Michael Heerdegen <michael_heerdegen@web.de> writes: > My question is: is this a bug, or intended behavior? If it is intended, > why, and is there a way to get the mouse highlighting nevertheless work > or to override the default behavior? In my scenario, it is important > that the mouse-face works also for strings consisting of newlines, to > indicate that it's clickable text. From my understanding, the mouse-face highlighting only triggers when the cursor is over a text character glyph, but this should not be a fundamental limitation, and is something we could change in future releases. I suggest filing a bug report. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-18 21:34 face vs. mouse-face text property Michael Heerdegen 2012-01-19 7:20 ` Chong Yidong @ 2012-01-19 12:19 ` Eli Zaretskii 2012-01-20 20:18 ` Michael Heerdegen 1 sibling, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2012-01-19 12:19 UTC (permalink / raw) To: emacs-devel, michael_heerdegen > From: Michael Heerdegen <michael_heerdegen@web.de> > Date: Wed, 18 Jan 2012 22:34:32 +0100 > Reply-To: emacs-devel@gnu.org, michael_heerdegen@web.de > > My question is: is this a bug, or intended behavior? It is intended behavior, in that the implementation of this feature explicitly supports mouse highlight only on the following parts of the display: . mode line . header line . left and right margins (NOT fringes!) . text > If it is intended, why, and is there a way to get the mouse > highlighting nevertheless work or to override the default behavior? There's no way around this current, no. > In my scenario, it is important that the mouse-face works also for > strings consisting of newlines, to indicate that it's clickable > text. Could you please describe your scenario in more detail? Empty lines have no text, so it's unclear how can you talk about "clickable text" in that case. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-19 12:19 ` Eli Zaretskii @ 2012-01-20 20:18 ` Michael Heerdegen 2012-01-21 10:09 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Michael Heerdegen @ 2012-01-20 20:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Could you please describe your scenario in more detail? Empty lines > have no text, so it's unclear how can you talk about "clickable text" > in that case. I'm talking about completion candidates that can be selected with the mouse. I stumbled over this problem in Icicles, but it also appears in vanilla Emacs. Try this: (completing-read "foo: " '(("aaaa") ("bbbb") ("\n") ("cccc"))) The "\n" candidate gets no visible mouse-face when you move the mouse over it in *Completions*, so the user doesn't see where to click to select it. If you try that: (completing-read "foo: " '(("a\n\nb"))) the whole area between a and b gets a mouse-face (from the left to the right border of the window), but only if the mouse is exactly over the a or the b. Such completion candidates are a bit exotic, right, but they _do_ appear in some situations. - Michael ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-20 20:18 ` Michael Heerdegen @ 2012-01-21 10:09 ` Eli Zaretskii 2012-01-22 22:21 ` Michael Heerdegen 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2012-01-21 10:09 UTC (permalink / raw) To: emacs-devel, michael_heerdegen > From: Michael Heerdegen <michael_heerdegen@web.de> > Cc: emacs-devel@gnu.org > Date: Fri, 20 Jan 2012 21:18:47 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > > Could you please describe your scenario in more detail? Empty lines > > have no text, so it's unclear how can you talk about "clickable text" > > in that case. > > I'm talking about completion candidates that can be selected with the > mouse. I stumbled over this problem in Icicles, but it also appears in > vanilla Emacs. Try this: > > (completing-read "foo: " '(("aaaa") ("bbbb") ("\n") ("cccc"))) > > The "\n" candidate gets no visible mouse-face when you move the mouse > over it in *Completions*, so the user doesn't see where to click to > select it. Thanks. But that's not what I meant. You gave a test case, but didn't explain how come "\n" winded up in the list of completion candidates. But let's take this particular example: How would you like the newline to be displayed for the user to understand there's a selectable newline there? If we replace the "\n" with a "_", the *Completions* display is like this: Possible completions are: _ aaaa bbbb cccc What would you say the display should look like with \n instead of _, and which part(s) of the corresponding screen line would need to be highlighted when the mouse hovers over the newline? Most importantly, given the display you want to see, how would the user understand she is suggested a selectable newline? > Such completion candidates are a bit exotic, right, but they _do_ appear > in some situations. Well, I asked for those _situations_ leading to these lists of candidates to be described. TIA. Also, are completion candidates the only situations where these problems arise? The original issue you raised was much more general, AFAIU. Btw, in Emacs 23, you couldn't even select such a newline, neither with a mouse click nor with a RET: you'd get "\naaaa" instead of a lone "\n". In Emacs 24, at least you can select the newline alone. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-21 10:09 ` Eli Zaretskii @ 2012-01-22 22:21 ` Michael Heerdegen 2012-01-23 6:48 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Michael Heerdegen @ 2012-01-22 22:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > But let's take this particular example: How would you like the newline > to be displayed for the user to understand there's a selectable > newline there? If we replace the "\n" with a "_", the *Completions* > display is like this: > > Possible completions are: > _ aaaa > bbbb cccc > > What would you say the display should look like with \n instead of _, > and which part(s) of the corresponding screen line would need to be > highlighted when the mouse hovers over the newline? Most importantly, > given the display you want to see, how would the user understand she > is suggested a selectable newline? If _ is replaced by a newline character, your example would look like that, I guess: Possible completions are: aaaa bbbb cccc since AFAIK the newline character breaks the visual line. So, the whole first line should be highlighted. The 'mouse-face property should appear exactly on the same space where a 'highlight property would be shown. Actually, this is already the case, but: the highlighting gets only "activated" when the mouse pointer is over a printable character. With other words: there is a discrepancy between what gets highlighted, and where the mouse pointer must be to get the highlighting shown. Currently, if there is a newline character, the highlighting is shown until the end of the line. But if I move the mouse pointer there, the highlighting disappears, although I never left the area of the highlighting. Besides, in the `completing-read' example, you can also _select_ the newline candidate when you click near the end of the line. So, currently, the space where the highlighting is "activated" also doesn't correspond to the space where the candidate can be selected. > Well, I asked for those _situations_ leading to these lists of > candidates to be described. TIA. - All commands that prompt for a piece of text to insert may show candidates including newlines, even empty lines. For example a command that prompts for an entry of the kill ring to insert, showing the available pieces of text as completion candidates (or clickable text). Many people use something like that. - dired. Some people like filenames including newlines. I don't, but I want that dired works for files with any name. filenames appear in *Completions* if you do C or R or something like that in dired. - In Icicles, there are many situations where candidates including newlines can appear, be it showing history items for `repeat-complex-command', or `icicle-search'. > Also, are completion candidates the only situations where these > problems arise? The original issue you raised was much more general, > AFAIU. It's not forbidden to mouse-face arbitrary multi-line text. E.g. in *ielm* or *shell*, if you move the mouse over a previous input, it is mouse-faced. There, input is allowed to be multiline. > Btw, in Emacs 23, you couldn't even select such a newline, neither > with a mouse click nor with a RET: you'd get "\naaaa" instead of a > lone "\n". In Emacs 24, at least you can select the newline alone. Good, that's an improvement. Thanks, Michael. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-22 22:21 ` Michael Heerdegen @ 2012-01-23 6:48 ` Eli Zaretskii 2012-01-23 14:27 ` Stefan Monnier 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2012-01-23 6:48 UTC (permalink / raw) To: michael_heerdegen; +Cc: emacs-devel > From: Michael Heerdegen <michael_heerdegen@web.de> > Cc: emacs-devel@gnu.org > Date: Sun, 22 Jan 2012 23:21:05 +0100 > > > Possible completions are: > > _ aaaa > > bbbb cccc > > > > What would you say the display should look like with \n instead of _, > > and which part(s) of the corresponding screen line would need to be > > highlighted when the mouse hovers over the newline? Most importantly, > > given the display you want to see, how would the user understand she > > is suggested a selectable newline? > > If _ is replaced by a newline character, your example would look like > that, I guess: > > Possible completions are: > > aaaa > bbbb cccc > > since AFAIK the newline character breaks the visual line. So, the whole > first line should be highlighted. Isn't that confusing, though? I think many users will not understand what they are being shown. Therefore, I think if we want to be able to display selectable newlines, we need to have a special way to display such newlines, e.g. "<NL>" or some such. > The 'mouse-face property should appear exactly on the same space where a > 'highlight property would be shown. Actually, this is already the case, > but: the highlighting gets only "activated" when the mouse pointer is > over a printable character. With other words: there is a discrepancy > between what gets highlighted, and where the mouse pointer must be to > get the highlighting shown. Currently, if there is a newline character, > the highlighting is shown until the end of the line. But if I move the > mouse pointer there, the highlighting disappears, although I never left > the area of the highlighting. Besides, in the `completing-read' > example, you can also _select_ the newline candidate when you click near > the end of the line. So, currently, the space where the highlighting is > "activated" also doesn't correspond to the space where the candidate can > be selected. These are all side effects of the fact that a newline has no glyph that is displayed on the screen. We are trying to highlight and select an object that doesn't exist on the screen. Again, if we want to handle these cases, we need some way of producing a tangible display of a newline. > - All commands that prompt for a piece of text to insert may show > candidates including newlines, even empty lines. For example a > command that prompts for an entry of the kill ring to insert, showing > the available pieces of text as completion candidates (or clickable > text). Many people use something like that. > > - dired. Some people like filenames including newlines. I don't, but I > want that dired works for files with any name. filenames appear in > *Completions* if you do C or R or something like that in dired. > > - In Icicles, there are many situations where candidates including > newlines can appear, be it showing history items for > `repeat-complex-command', or `icicle-search'. Candidates that just include newlines are not the problem. Candidates that include _only_ newlines are. Anyway, please feel free to file a wishlist bug report about this. Thanks. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-23 6:48 ` Eli Zaretskii @ 2012-01-23 14:27 ` Stefan Monnier 2012-01-23 14:43 ` Lennart Borgman 0 siblings, 1 reply; 21+ messages in thread From: Stefan Monnier @ 2012-01-23 14:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, emacs-devel > Therefore, I think if we want to be able to display selectable > newlines, we need to have a special way to display such newlines, > e.g. "<NL>" or some such. I'd suggest \n rather than <NL>, since it's already used at many other places in Emacs (tho it's not often visible to the "end user"). There are other similar issues in the *Completions* lists if you have completions which start/end with spaces or tabs, are very long, or worse only contain spaces or tabs: while the mouse-over will be reasonably clear, the list is far from clear if you don't move your mouse over it to see the exact boundaries. Currently, completions are used for entities which typically don't suffer from such issues. But if we want to use it for things like yank-browse (see sample code below), we need to make it handle such cases a bit better. Stefan (defun yank-browse (string) "Browse the `kill-ring' to choose which entry to yank." (interactive (minibuffer-with-setup-hook #'minibuffer-completion-help (let* ((kills (delete-dups (append kill-ring-yank-pointer kill-ring nil))) (entries (mapcar (lambda (string) (let ((pos 0)) ;; FIXME: Maybe we should start by removing ;; all properties. (setq string (copy-sequence string)) (while (string-match "\n" string pos) ;; FIXME: Maybe completion--insert-strings should ;; do that for us. (put-text-property (match-beginning 0) (match-end 0) 'display (eval-when-compile (propertize "\\n" 'face 'escape-glyph)) string) (setq pos (match-end 0))) ;; FIXME: We may use the window-width of the ;; wrong window. (when (>= (* 3 (string-width string)) (* 2 (window-width))) (let ((half (- (/ (window-width) 3) 1))) ;; FIXME: We're using char-counts rather than ;; width-count. (put-text-property half (- (length string) half) 'display (eval-when-compile (propertize "……" 'face 'escape-glyph)) string))) string)) kills)) (table (lambda (string pred action) (cond ((eq action 'metadata) '(metadata (category . kill-ring))) (t (complete-with-action action entries string pred)))))) ;; FIXME: We should return the entry from the kill-ring rather than ;; the entry from the completion-table. ;; FIXME: substring completion doesn't work well because it only matches ;; subtrings before the first \n. ;; FIXME: completion--insert-strings assumes that boundaries of ;; candidates are obvious enough, but with kill-ring entries this is not ;; true, so we'd probably want to display them with «...» around them. (list (completing-read "Yank: " table nil t))))) (setq this-command 'yank) (insert-for-yank string)) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-23 14:27 ` Stefan Monnier @ 2012-01-23 14:43 ` Lennart Borgman 2012-01-23 15:34 ` Stefan Monnier 0 siblings, 1 reply; 21+ messages in thread From: Lennart Borgman @ 2012-01-23 14:43 UTC (permalink / raw) To: Stefan Monnier; +Cc: michael_heerdegen, Eli Zaretskii, emacs-devel On Mon, Jan 23, 2012 at 15:27, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> Therefore, I think if we want to be able to display selectable >> newlines, we need to have a special way to display such newlines, >> e.g. "<NL>" or some such. > > I'd suggest \n rather than <NL>, since it's already used at many other > places in Emacs (tho it's not often visible to the "end user"). Why not show "\n" with a special background face? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-23 14:43 ` Lennart Borgman @ 2012-01-23 15:34 ` Stefan Monnier 2012-01-23 15:40 ` Lennart Borgman 0 siblings, 1 reply; 21+ messages in thread From: Stefan Monnier @ 2012-01-23 15:34 UTC (permalink / raw) To: Lennart Borgman; +Cc: michael_heerdegen, Eli Zaretskii, emacs-devel >>> Therefore, I think if we want to be able to display selectable >>> newlines, we need to have a special way to display such newlines, >>> e.g. "<NL>" or some such. >> I'd suggest \n rather than <NL>, since it's already used at many other >> places in Emacs (tho it's not often visible to the "end user"). > Why not show "\n" with a special background face? Which part of (propertize "\\n" 'face 'escape-glyph) makes you think that we wouldn't want to show \n with a special background face? Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-23 15:34 ` Stefan Monnier @ 2012-01-23 15:40 ` Lennart Borgman 2012-01-23 18:47 ` chad 0 siblings, 1 reply; 21+ messages in thread From: Lennart Borgman @ 2012-01-23 15:40 UTC (permalink / raw) To: Stefan Monnier; +Cc: michael_heerdegen, Eli Zaretskii, emacs-devel On Mon, Jan 23, 2012 at 16:34, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >>>> Therefore, I think if we want to be able to display selectable >>>> newlines, we need to have a special way to display such newlines, >>>> e.g. "<NL>" or some such. >>> I'd suggest \n rather than <NL>, since it's already used at many other >>> places in Emacs (tho it's not often visible to the "end user"). >> Why not show "\n" with a special background face? > > Which part of (propertize "\\n" 'face 'escape-glyph) makes you think > that we wouldn't want to show \n with a special background face? ;-) Sorry. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-23 15:40 ` Lennart Borgman @ 2012-01-23 18:47 ` chad 2012-01-23 20:44 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: chad @ 2012-01-23 18:47 UTC (permalink / raw) To: Emacs developers On Mon, Jan 23, 2012 at 16:34, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> Therefore, I think if we want to be able to display selectable >> newlines, we need to have a special way to display such newlines, >> e.g. "<NL>" or some such. > > I'd suggest \n rather than <NL>, since it's already used at many other > places in Emacs (tho it's not often visible to the "end user"). Maybe  and ⇥ would be useful here? *Chad ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-23 18:47 ` chad @ 2012-01-23 20:44 ` Eli Zaretskii 2012-01-23 21:09 ` chad 2012-01-24 15:01 ` Stefan Monnier 2012-01-24 16:49 ` Richard Stallman 2 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2012-01-23 20:44 UTC (permalink / raw) To: chad; +Cc: emacs-devel > From: chad <yandros@gmail.com> > Date: Mon, 23 Jan 2012 10:47:02 -0800 > > On Mon, Jan 23, 2012 at 16:34, Stefan Monnier <monnier@iro.umontreal.ca> wrote: > >> Therefore, I think if we want to be able to display selectable > >> newlines, we need to have a special way to display such newlines, > >> e.g. "<NL>" or some such. > > > > I'd suggest \n rather than <NL>, since it's already used at many other > > places in Emacs (tho it's not often visible to the "end user"). > > Maybe  and ⇥ would be useful here? What will that do on a TTY? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-23 20:44 ` Eli Zaretskii @ 2012-01-23 21:09 ` chad 2012-01-24 3:48 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: chad @ 2012-01-23 21:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 378 bytes --] On Jan 23, 2012, at 12:44 PM, Eli Zaretskii wrote: >> From: chad <yandros@gmail.com> >> Maybe  and ⇥ would be useful here? > > What will that do on a TTY? The same thing that quotation marks do, ala: http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00649.html and http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00722.html *Chad [-- Attachment #2: Type: text/html, Size: 1175 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-23 21:09 ` chad @ 2012-01-24 3:48 ` Eli Zaretskii 2012-01-24 5:55 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2012-01-24 3:48 UTC (permalink / raw) To: chad; +Cc: emacs-devel > From: chad <yandros@gmail.com> > Date: Mon, 23 Jan 2012 13:09:45 -0800 > Cc: emacs-devel@gnu.org > > > [1:text/plain Hide] > > On Jan 23, 2012, at 12:44 PM, Eli Zaretskii wrote: > > >> From: chad <yandros@gmail.com> > >> Maybe  and ⇥ would be useful here? > > > > What will that do on a TTY? > > > The same thing that quotation marks do The characters you propose are much less popular, so run greater risk of being not covered by the console fonts. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-24 3:48 ` Eli Zaretskii @ 2012-01-24 5:55 ` Eli Zaretskii 2012-01-24 7:04 ` chad 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2012-01-24 5:55 UTC (permalink / raw) To: yandros, emacs-devel > Date: Tue, 24 Jan 2012 05:48:25 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: emacs-devel@gnu.org > > > >> From: chad <yandros@gmail.com> > > >> Maybe  and ⇥ would be useful here? > > > > > > What will that do on a TTY? > > > > > > The same thing that quotation marks do > > The characters you propose are much less popular, so run greater risk > of being not covered by the console fonts. E.g., PuTTY in UTF-8 display mode shows them as empty rectangles. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-24 5:55 ` Eli Zaretskii @ 2012-01-24 7:04 ` chad 2012-01-24 9:11 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: chad @ 2012-01-24 7:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On Jan 23, 2012, at 9:55 PM, Eli Zaretskii wrote: >> Date: Tue, 24 Jan 2012 05:48:25 +0200 >> From: Eli Zaretskii <eliz@gnu.org> >> Cc: emacs-devel@gnu.org >> >>>>> From: chad <yandros@gmail.com> >>>>> Maybe  and ⇥ would be useful here? >>>> >>>> What will that do on a TTY? >>> >>> >>> The same thing that quotation marks do >> >> The characters you propose are much less popular, so run greater risk >> of being not covered by the console fonts. > > E.g., PuTTY in UTF-8 display mode shows them as empty rectangles. I trust your experience far more than mine these days, but I have to wonder if empty rectangle might not be good enough for the suggested use case. I assume that C-x = DTRT with those empty rectangles? *Chad ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-24 7:04 ` chad @ 2012-01-24 9:11 ` Eli Zaretskii 2012-01-24 11:14 ` chad 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2012-01-24 9:11 UTC (permalink / raw) To: chad; +Cc: emacs-devel > From: chad <yandros@gmail.com> > Date: Mon, 23 Jan 2012 23:04:39 -0800 > Cc: emacs-devel@gnu.org > > >> The characters you propose are much less popular, so run greater risk > >> of being not covered by the console fonts. > > > > E.g., PuTTY in UTF-8 display mode shows them as empty rectangles. > > I trust your experience far more than mine these days, but I have to wonder if empty rectangle might not be good enough for the suggested use case. I doubt that. The issue at hand is how to display mouse-highlighted newline so that it is clear to the user it's a newline that (e.g.) will be inserted when she clicks on it in *Completions* buffer. Showing an empty rectangle hardly accomplishes that effect. > I assume that C-x = DTRT with those empty rectangles? You meant "C-u C-x =", I presume. This does show the name of the character, but you should have the cursor on it, which might be tricky in the *Completions* buffer. Also, at least some methods of displaying something instead of a newline (e.g., display strings) cause "C-x =" to display information about the underlying character, which may or may not explain what is being shown and why. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-24 9:11 ` Eli Zaretskii @ 2012-01-24 11:14 ` chad 0 siblings, 0 replies; 21+ messages in thread From: chad @ 2012-01-24 11:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1550 bytes --] On Jan 24, 2012, at 1:11 AM, Eli Zaretskii wrote: >> >> I trust your experience far more than mine these days, but I have to wonder if empty rectangle might not be good enough for the suggested use case. > > I doubt that. The issue at hand is how to display mouse-highlighted > newline so that it is clear to the user it's a newline that (e.g.) > will be inserted when she clicks on it in *Completions* buffer. > Showing an empty rectangle hardly accomplishes that effect. I suppose that there are tricky edges, but I thought that the first-order problem was being able to tell a newline or tab apart from nothing. If the use-case is more complicated, then I'll certainly believe that `something not-normal but not-nothing' is not sufficient. I had mostly hoped to improve upon Lars' `4 chars of garbage' experience. > >> I assume that C-x = DTRT with those empty rectangles? > > You meant "C-u C-x =", I presume. Yes, that's what I meant; thanks. In truth, I have quite a bit of very old tty-only experience, but almost all of it predates reasonable tty+mouse setups, so I tend to forget the mouse part in this domain. I did check that mouse-selecting such a character in order to describe-char it was a bust, but I assumed (probably wrongly) that the mouse-case wasn't as interesting for the tty users as a the keyboard-motion case. For the mouse case, I was wondering idly about a tooltip version of describe-char, but it seemed unlikely to be as useful as a special face for this purpose. Thanks! *Chad [-- Attachment #2: Type: text/html, Size: 2105 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-23 18:47 ` chad 2012-01-23 20:44 ` Eli Zaretskii @ 2012-01-24 15:01 ` Stefan Monnier 2012-01-24 16:49 ` Richard Stallman 2 siblings, 0 replies; 21+ messages in thread From: Stefan Monnier @ 2012-01-24 15:01 UTC (permalink / raw) To: chad; +Cc: Emacs developers >>> Therefore, I think if we want to be able to display selectable >>> newlines, we need to have a special way to display such newlines, >>> e.g. "<NL>" or some such. >> I'd suggest \n rather than <NL>, since it's already used at many other >> places in Emacs (tho it's not often visible to the "end user"). > Maybe  and ⇥ would be useful here? Maybe, but I think not: I don't think "" is more commonly recognized as newline than "\n", so it's not worth the trouble of having to deal with cases where that char can't be displayed. Same thing for ⇥ (which on my current setup displays as something barely recognizable): I actually wondered what you intended to use it for, so it's not obvious enough. I think for TAB and SPC, the problem is only when they're at the beginning/end of the completion element (or when the element is made of nothing else than TABs and SPCs), so I think that adding quotes around the element will be more clear. Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: face vs. mouse-face text property 2012-01-23 18:47 ` chad 2012-01-23 20:44 ` Eli Zaretskii 2012-01-24 15:01 ` Stefan Monnier @ 2012-01-24 16:49 ` Richard Stallman 2 siblings, 0 replies; 21+ messages in thread From: Richard Stallman @ 2012-01-24 16:49 UTC (permalink / raw) To: chad; +Cc: emacs-devel Maybe  and ⇥ would be useful here? They both appear as a diamond shape for me. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use free telephony http://directory.fsf.org/category/tel/ ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2012-01-24 16:49 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-01-18 21:34 face vs. mouse-face text property Michael Heerdegen 2012-01-19 7:20 ` Chong Yidong 2012-01-19 12:19 ` Eli Zaretskii 2012-01-20 20:18 ` Michael Heerdegen 2012-01-21 10:09 ` Eli Zaretskii 2012-01-22 22:21 ` Michael Heerdegen 2012-01-23 6:48 ` Eli Zaretskii 2012-01-23 14:27 ` Stefan Monnier 2012-01-23 14:43 ` Lennart Borgman 2012-01-23 15:34 ` Stefan Monnier 2012-01-23 15:40 ` Lennart Borgman 2012-01-23 18:47 ` chad 2012-01-23 20:44 ` Eli Zaretskii 2012-01-23 21:09 ` chad 2012-01-24 3:48 ` Eli Zaretskii 2012-01-24 5:55 ` Eli Zaretskii 2012-01-24 7:04 ` chad 2012-01-24 9:11 ` Eli Zaretskii 2012-01-24 11:14 ` chad 2012-01-24 15:01 ` Stefan Monnier 2012-01-24 16:49 ` Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.