bug#36550: mouse-face overlay calculation error

["Linus Källberg" <linus.kallberg@outlook.com>]

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