bug#36550: mouse-face overlay calculation error

[Eli Zaretskii <eliz@gnu.org>]

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

> I would expect it to end after the last character before the newline

Can't do that, because the newline is also covered by the face.

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

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

> However, due to the "bug" in question (if it is indeed a bug), when
> hovering the mouse over a link, the whole line (up to the right edge
> of the window) and the first character on the next line is
> highlighted. I have been using Emacs, and the recentf package, for
> only five years, but I always thought that this looked ugly and
> somewhat "buggy". The other day I was a bit cranky and decided to
> look into it :-)

Indeed, the mouse-face should end before the newline.

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

Thanks.