bug#36550: mouse-face overlay calculation error

[Lars Ingebrigtsen <larsi@gnus.org>]

Eli Zaretskii <eliz@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@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