Re: flyspell + longlines: hang/wait

[David Reitter]

On 26 Oct 2005, at 11:27, Miles Bader wrote:

> 2005/10/26, David Reitter <address@hidden>:
>
> > (It's still unnecessary, as flyspell shouldn't be checking the entire
> > buffer just because longlines has re-wrapped the text -- if this is
> > what's happening here!)
>
> If so, presumably flyspell just re-checks any changed text regions,
> and doesn't realize the changes are innocuous in this case (i'm not
> sure how it could);

Another reason not to implement soft line wrapping as actual  
modifications of the buffer.

Let me summarize the discussion people had on emacs-devel back in July:

Kim F Storm posted a patch to the display routines (emacs-devel, 21  
Jul 05 15.25) that does it the way pretty much all editors implement  
soft wrapping: transparent to any text processing algorithms, soft  
line breaks only occur in the screen display. The other advantage is  
that you don't need to reformat the whole buffer just because the  
user changes the frame size (i.e. the line length) and things work  
fine with variable-width fonts (Chong Yidong, 22 Jul 2005: "One thing  
that longlines.el is unlikely ever to accomplish is support for  
proportional fonts and images").

If you look at how fast editors rewrap text while you're typing or  
during redraw, and if you compare that to Emacs sluggish behavior,  
you have a pretty strong argument to not implement soft wrapping as a  
case of undoable hard-wrapping.

The technical change seems minimal. As Kim states (22 Jul 2005): "It  
is no different from how continued lines are handled in the current  
code.  The only real difference is that continued lines break at  
spaces rather than at some arbitrary column which happens to be the  
width of the window."

David Kastrup mentions another argument (21 Jul):  "The only real  
difference is that continued lines break at spaces rather than at  
some arbitrary column which happens to be the width of the window."  
He argues for a combination of display-engine and buffer level line  
wrapping in order to enforce a maximum line width in the output file,  
which would, as I think, a fantastic feature that is probably too  
difficult to design for the upcoming release.

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)


> perhaps longlines mode could bind some variable
> while refilling (or the general filling code could) that said
> "whitespace changes only, no need to worry", and flyspell could
> somehow pay attention to that...

Sure, it could. But that'd be quite an ad-hoc hack.

smime.p7s
Description: S/MIME cryptographic signature