[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#36550: mouse-face overlay calculation error

From: Lars Ingebrigtsen
Subject: bug#36550: mouse-face overlay calculation error
Date: Sat, 13 Jul 2019 16:25:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Lars Ingebrigtsen <address@hidden>
>> Cc: address@hidden,  address@hidden
>> Date: Sat, 13 Jul 2019 15:50:41 +0200
>> commit 5d24c60e3a3b07ccb31b886885ea117a058168be
>> Author: David Ponce <address@hidden>
>> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]