bug#36550: mouse-face overlay calculation error

[Lars Ingebrigtsen <larsi@gnus.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: 36550@debbugs.gnu.org,  linus.kallberg@outlook.com
>> Date: Sat, 13 Jul 2019 15:50:41 +0200
>> 
>> commit 5d24c60e3a3b07ccb31b886885ea117a058168be
>> Author: David Ponce <david@dponce.com>
>> Date:   Mon Apr 3 14:34:28 2006 +0000
>> 
>>     (recentf-open-files-item): Include newline in button
>>     field, so opening a file will work, when the point is at the end
>>     of the file name.  Allow, for example, to [i]search a file by
>>     extension and just push RET to open it.
>> 
>> So it really wants the widget to have the newline inside the widget for
>> usability reasons.
>
> I still don't understand why.  Surely, "the end of the file name" is
> before the newline, right?

I am not sure; I don't use recentf...

> And what point has to do with that, since mouse-face is about the
> mouse pointer, not about point?  What am I missing here?

The widget consists of text in the buffer and a bunch of overlays
(including keymap overlays), and the mouse-face overlay is one of them.
My guess is that the committer wanted the keymap to be on the newline so
that it's in effect when typing?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no