Re: flyspell + longlines: hang/wait

[Kim F. Storm]

David Reitter <address@hidden> writes:

>
> This doesn't have to be implemented in the way Kim's patch suggested.
> RMS had another idea, with overlays causing the text to break at
> convenient places. These wouldn't be seen as line-breaks by most
> commands, but:
>
> "The ideas is that most commands that examine the buffer contents would
> see the result of the overlays.  So cursor motion commands would treat
> the apparent newline as a real newline, and treat the apparent space
> as a real space.  Only things that copy text (including kill and yank,
> and file I/O) would ignore them." (RMS, 23 Jul 2005)

I may be wrong, but will commands which "examine the buffer contents"
really "see the result of the overlays" ??

What property of the overlay does this?

The 'display property certainly doesn't do it.

For example, put this into a buffer:

------------------- cut here -----------------
abcdef ghijklm nopqrst uvwxyz

(progn (setq ov (make-overlay 23 24))
 (overlay-put ov 'display "\n"))
------------------- cut here -----------------

Go to the end of the buffer and do C-x C-e to evaluate
the lisp expression.

As a result, the first line is broken at the last space like this:

abcdef ghijklm nopqrst
uvwxyz

Now, move the cursor to the `a' ont the first line, and use C-e
to go to the end of that line... and  the cursor goes after `z'.
Also try C-n C-n C-p C-p etc. to move around in the buffer.

Its been too long for me to remember exactly how my patch handled this
situation, but IIRC, it suffered from the same problem (which IIUC was
the primary reason why RMS didn't like my approach).

Still, my patch only required you to set a single variable and not
modify any buffer contents -- for the user that's a good deal simpler
(and it works just as good/bad as continuation lines are handled now).

-- 
Kim F. Storm <address@hidden> http://www.cua.dk