bug#36550: mouse-face overlay calculation error

[Linus Källberg]

Den 2019-07-13 kl. 17:08, skrev Lars Ingebrigtsen:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> OK, but then they simply should use a separate overlay for the
>>> mouse-face, I think, one that doesn't cover the newline.  Does that
>>> solve the problem?
>>
>> Yes, I can hack wid-edit.el as previously suggested.
> 
> OK, I took another look at the wid-edit.el code which reminded me that
> it's not that simple, because it does a lot of manipulation of the
> overlays in the most tedious way.
> 
> So I'll just leave this for somebody else to fix one rainy day...

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). I would expect it to end after 
the last character before the newline, or possibly one character further 
to the right (as if there was an imaginary space character inserted 
there). As was said earlier, it doesn't make sense to highlight parts of 
a line that doesn't contain clickable text.

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

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:

diff --git "a/lisp/recentf.el" "b/lisp/recentf.el"
index 4112b44e48..5d832a9d37 100644
--- "a/lisp/recentf.el"
+++ "b/lisp/recentf.el"
@@ -1179,9 +1179,9 @@ IGNORE other arguments."
      ;; Represent a single file with a link widget
      `(link :tag ,(car menu-element)
             :button-prefix ""
-           :button-suffix ""
+           :button-suffix " "
             :button-face default
-           :format "%[%t\n%]"
+           :format "%[%t%]\n"
             :help-echo ,(concat "Open " (cdr menu-element))
             :action recentf-open-files-action
             ;; Override the (problematic) follow-link property of the

Best regards,
Linus Källberg