face vs. mouse-face text property

face vs. mouse-face text property

[Michael Heerdegen]

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.

Re: face vs. mouse-face text property

[Chong Yidong]

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.

Re: face vs. mouse-face text property

[Eli Zaretskii]

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

Re: face vs. mouse-face text property

[Michael Heerdegen]

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

Re: face vs. mouse-face text property

[Eli Zaretskii]

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

Re: face vs. mouse-face text property

[Michael Heerdegen]

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.

Re: face vs. mouse-face text property

[Eli Zaretskii]

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

Re: face vs. mouse-face text property

[Stefan Monnier]

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

Re: face vs. mouse-face text property

[Lennart Borgman]

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?

Re: face vs. mouse-face text property

[Stefan Monnier]

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

Re: face vs. mouse-face text property

[Lennart Borgman]

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.

Re: face vs. mouse-face text property

[chad]

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

Re: face vs. mouse-face text property

[Eli Zaretskii]

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

Re: face vs. mouse-face text property

[chad]

[-- 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 --]

Re: face vs. mouse-face text property

[Eli Zaretskii]

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

Re: face vs. mouse-face text property

[Eli Zaretskii]

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

Re: face vs. mouse-face text property

[chad]

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

Re: face vs. mouse-face text property

[Eli Zaretskii]

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

Re: face vs. mouse-face text property

[chad]

[-- 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 --]

Re: face vs. mouse-face text property

[Stefan Monnier]

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

Re: face vs. mouse-face text property

[Richard Stallman]

    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/