bug#36550: mouse-face overlay calculation error

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 36550@debbugs.gnu.org,  linus.kallberg@outlook.com
> Date: Sat, 13 Jul 2019 15:10:05 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Mouse-face isn't supposed to cover newlines, I think.  Why do you need
> > that?
> 
> Because Widget wants to have the mouse-face extend to the end of the
> line, I think...

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.

> > The "one character shorter" variant does what it's expected to do,
> > because mouse-face is not extended to EOL as with other faces.
> > Mouse-face is for showing the parts of text that are mouse-sensitive,
> > so it makes no sense to highlight portions of display that have no
> > text.
> 
> OK, if this is how mouse-face is supposed to work, then the fix in
> wid-edit.el should be pretty trivial -- I'll just have it not put the
> overlay on the newline?

Yes, I think so.

> > It's in the display code, and is quite complicated due to
> > bidirectional text use case.  See mouse_face_from_buffer_pos and its
> > subroutine rows_from_pos_range.
> 
> 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.