bug#17244: 24.3.90; `line-move-visual' errors when moving across wrapped lines with an overlay property of 'display

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 11 Apr 2014 15:28:55 -0600
> From: Ivan Andrus <darthandrus@gmail.com>
> 
> Starting from Emacs -Q, create a buffer with the following contents.
> Notice that the first two (2) lines are blank, and the next is one long
> line (in case it gets broken by email)
> 
> #### buffer start:
> 
> 
> ;; I think this needs to be really long here.  Why?  I don't really know,
> but a guess.  I think this needs to be really long here.  Why?  I don't
> really know, but a guess.  I think this needs to be really long here.  Why?
>  I don't really know, but a guess.  I think this needs to be really long
> here.  Why?  I don't really know, but a guess.  I think this needs to be
> really long here.  Why?  I don't really know, but a guess.  I think this
> needs to be really long here.  Why?  I don't really know, but a guess.
> (let ((ov (make-overlay 3 515)))
>  (overlay-put ov 'display "hi\n"))
> (line-move-visual -5)
> 
> 1. Make sure the window is skinny enough that the comment line wraps.
> 2. Evaluate the first form, creating an overlay.
> 3. Evaluate the second form.  It is important that point be at the end
>    of the "line-move-visual" line.
> 4. You get a warning about beginning-of-buffer, when it clearly did not
>    reach the beginning-of-buffer.
> 
> As near as I can tell, the incorrect error message is because it doesn't
> move as far at it thinks it should (the real bug), and it assumes the
> reason it didn't is because it made it to the beginning (or end) of the
> buffer.

Thanks for the report.  I fixed this in revision 116947 on the
emacs-24 branch.

<rant>
To tell the truth, Lisp code which covers large portions of buffer
text with much shorter display strings that include newlines deserves
to be broken.  The current Emacs display engine was never designed to
handle situations where the displayed text is so starkly different
from buffer text, so the result of trying to fix "bugs" such as this
one is a never-ending series of band-aids, one upon the other, which
make the code utterly incomprehensible and unmaintainable.

So I'm this close to refusing to fix such "bugs", and instead asking
the authors of such Lisp to either find more benign ways of expressing
what they need, or work around the limitations of the display engine
in their own Lisp.
</rant>