Re: flyspell + longlines: hang/wait

[Richard M. Stallman]

    - wrong line-breaks with variable-width fonts

We need functions to compute widths taking faces into account.
With them, it will be easy to fix this.

    - line numbers displayed are plain wrong

Would you please explain what you mean?  Whether they are right or
wrong might be a matter of interpretation.

    - incredibly slow with large files, even when resizing the frame  
    (with the appropriate customization set)

That is a real drawback.

    - the interaction with flyspell (and whatnot) that has been discussed  
    here.

That should be easy to fix.

    All of those bugs go back to the (incredible) design that implements  
    a manipulation of the way data is displayed as an actual manipulation  
    of the underlying data.

The Emacs buffer is not merely a part of a system that we maintain.
It is a data structure that thousands of Lisp programs rely on.
`forward-line' is among the most common functions for user programs to
call.  If we change the data representation so that `forward-line' no
longer works in a useful way, that would be a much worse problem than
the ones above.

Some have argued that line-breaking at display time is equivalent to
continuation lines.  That ignores the way they would be USED.  The way
today's continuation lines are used, it is natural that `forward-line'
moves over all of them.  The line that is continued is meant to be a
single line; it just happens to be too wide for the screen.

A paragraph is NOT meant to be a single line, and if it appears as
one, that is very inconvenient.

    Model-View-Controller was invented for a  
    reason...

If you want to look at it that way, the Emacs buffer is the Model.
You're proposing an incompatible change in the model that would break
lots of user code.

I don't necessarily mind changes in how the buffer contents are
represented internally, but when ordinary user Lisp code looks at it,
it should see newlines between the lines of a paragraph.  And when the
user goes to a line number, this should not count each paragraph as
one line.  As you move up and down in the paragraph, the current line
number should change based on the lines that you see.

I suggested the idea of a new feature which would allow an overlay to
disguise the text, making a space appear as a newline or vice versa.
That would get rid of the slowness with things like flyspell mode, at
least.  Changes in these overlays would not run change hooks.
But this idea may not really help much.

What could we do to make the reformatting fast while preserving the
compatibility of buffer representations?  One idea would be to
implement the processing in C code.  As long as it is just replacement
of one character with another, it could be very fast.  If there is a
left-margin, it would not be so fast, but still faster than now.

Note that storing a paragraph as a single line inside Emacs would not
eliminate the need to reformat.  It would have to be done when reading
and writing files.  Reading would have to convert most newlines in the
file to spaces.  Writing would have to convert some of the spaces back
to newlines.  I don't think this would be faster; it could be slower.
After all, reading and writing files is much more common than resizing
frames.