[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36550: mouse-face overlay calculation error
From: |
Linus Källberg |
Subject: |
bug#36550: mouse-face overlay calculation error |
Date: |
Sat, 13 Jul 2019 19:49:07 +0000 |
Den 2019-07-13 kl. 17:49, skrev Eli Zaretskii:
>> From: Linus Källberg <linus.kallberg@outlook.com>
>> CC: "36550@debbugs.gnu.org" <36550@debbugs.gnu.org>
>> Date: Sat, 13 Jul 2019 15:38:05 +0000
>>
>> I might have misunderstood the discussion, but just to clarify my
>> opinion, if the overlay ends with a newline character, the mouse-face
>> should *not* extend to the right edge of the window (and definitely not
>> to the first character on the next line).
>
> But that's not what mouse-face means and does. It highlights
> mouse-sensitive text, and thus it should NOT include a newline,
> because a newline does not have a glyph in the buffer text. That's
> why you see the 1st character on the next line highlighted: it's the
> next character after the newline, and since the newline is absent, it
> gets highlighted instead, because when character positions are not
> monotonous with screen coordinates, we have no alternative but
> highlight that next character.
Are you saying that the mouse-face property should not be used on
overlays that contain newline characters, period, or simply those that
have a newline character as their *last* character? I must say, it does
seem like a bug that the appearance of characters not even included in
the overlay (i.e., the first character on the next line) is changed when
hovering the mouse over it.
I understand that a newline character cannot be clicked or highlighted
if it has no glyph in the text, but why can't it then simply not be
highlighted? Why must the first character on the next line be
highlighted instead? No doubt it is difficult to change this behavior
due to the complicated logic involved, but is it really intended, in the
sense that something else would break if it was "fixed"?
>> or possibly one character further to the right (as if there was an
>> imaginary space character inserted there).
>
> Can't do that, because that imaginary character doesn't exist, and
> therefore we cannot possible access its buffer position.
But doesn't it already do that? I use an Emacs theme that underlines
highlighted text, and when an overlay contains a newline character
(anywhere, not necessarily at the end), there is always one extra
"imaginary" character underlined after the last character before the
line break.
In this example, there is one extra underlined character after "foo":
(progn
(load-theme 'wombat t)
(let ((point (point)))
(insert "foo\nbar")
(let ((o (make-overlay point (point))))
(overlay-put o 'mouse-face 'highlight))))
>> In recentf, the newline after the file name is included in each link so
>> that if point is positioned right after the last character -- which
>> happens, e.g., if one i-searches for a file extension -- one can simply
>> press enter to open the file (as said in the commit message).
>
> But pressing Enter doesn't require mouse-face, does it? It requires
> an overlay with a suitable keymap property, right?
Exactly, I guess the button widget simply uses the same overlay for
everything.
>> As I said earlier, one way to fix the issue in recentf is simply to move
>> the newline outside of the link, but put a space character after each
>> file name. This way, the mouse-over highlights look okay, and one can
>> still i-search for a file extension and then simply press enter. Here is
>> a patch that does this:
>
> If this fixes the issue, it's fine with me. However, I think we
> should have a comment there explaining why we add this space
> character.
Yes, a comment should be added. However, I would prefer fixing the real
problem, which, if not in the display code, might be in the
implementation of the button widget.
Best regards,
Linus Källberg
- bug#36550: mouse-face overlay calculation error, (continued)
- bug#36550: mouse-face overlay calculation error, Lars Ingebrigtsen, 2019/07/13
- bug#36550: mouse-face overlay calculation error, Eli Zaretskii, 2019/07/13
- bug#36550: mouse-face overlay calculation error, Lars Ingebrigtsen, 2019/07/13
- bug#36550: mouse-face overlay calculation error, Eli Zaretskii, 2019/07/13
- bug#36550: mouse-face overlay calculation error, Lars Ingebrigtsen, 2019/07/13
- bug#36550: mouse-face overlay calculation error, Eli Zaretskii, 2019/07/13
- bug#36550: mouse-face overlay calculation error, Lars Ingebrigtsen, 2019/07/13
- bug#36550: mouse-face overlay calculation error, Lars Ingebrigtsen, 2019/07/13
- bug#36550: mouse-face overlay calculation error, Linus Källberg, 2019/07/13
- bug#36550: mouse-face overlay calculation error, Eli Zaretskii, 2019/07/13
- bug#36550: mouse-face overlay calculation error,
Linus Källberg <=
- bug#36550: mouse-face overlay calculation error, Eli Zaretskii, 2019/07/14