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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.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 17:17:54 +0300

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

> Well, it's not 100% right, since it highlights the first character on
> the next line if you have mouse-face on the preceding newline, which has
> to be a bug even if we're not supposed to put mouse-face on the newline.
> :-)

No, it's 100% right, because it implements a certain set of
requirements, and those mandate that when the end point is beyond the
last character on a line, that end point is in the next line.

Previous Next

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