GNU bug report logs - #36550
Small bug fix in recentf.el

Previous Next

Full log

Message #38 received at 36550 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36550 <at> debbugs.gnu.org, linus.kallberg <at> outlook.com
Subject: Re: bug#36550: mouse-face overlay calculation error
Date: Sat, 13 Jul 2019 16:25:35 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Cc: 36550 <at> debbugs.gnu.org,  linus.kallberg <at> outlook.com
>> Date: Sat, 13 Jul 2019 15:50:41 +0200
>> 
>> commit 5d24c60e3a3b07ccb31b886885ea117a058168be
>> Author: David Ponce <david <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.