GNU bug report logs -
#36550
Small bug fix in recentf.el
Previous Next
Full log
Message #32 received at 36550 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I don't understand why Widget would want to do that. As I explained,
> it makes no sense to highlight parts of display that have no text with
> a face that shows mouse-sensitive text. When the next line's
> characters are also sensitive, then yes, we do highlight all the way
> to the newline.
This is the commit that introduced the problem:
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 can special-case this in wid-edit.el -- if the final character in the
region is a newline, then all the other overlays extend all the way, but
mouse-face stops just short of the newline. But it's more than a bit
hacky...
>> Oh, wow; that's a daunting function indeed...
>
> Yes. The problem it tries to solve is to highlight correctly when
> buffer positions do not increment monotonously with screen
> coordinates. Unsurprisingly, at the time it took me some time to get
> that code right.
I see.
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.
:-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
This bug report was last modified 5 years and 338 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.