Re: flyspell + longlines: hang/wait

[David Reitter]

On 27 Oct 2005, at 02:31, Richard M. Stallman wrote:
>     - 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.

This is the crucial point.

> 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.


Let me give you two examples.

- I've been doing some work in Python lately. Python enforces strict  
formatting, and you don't have the option of inserting a newline at  
almost arbitrary (whitespace) positions like in C, for example. Two  
wrap lines, you need special syntax. Sometimes, lines get very long.  
Apart from the fact that the underlying programming style isn't  
ideal, these things happen.
I would like to display these lines - and they are and need to be  
single lines in the source - wrapped at a whitespace position, not in  
the middle of a word. Yet I need to jump to lines by their original  
number and identify them, because compiler and runtime errors refer  
to code by line number. (Yes, I want up/down movements to respect  
what's visible on the screen. But everything else should behave as if  
the 'soft' newlines didn't exist!)

- LaTeX. Sometimes I edit my document with a narrow frame, sometimes  
with a larger one. Screen real-estate is limited, and I often like to  
have several things open to copy/paste etc. Therefore, I'd like text  
to be rewrapped to use up the screen. (I need variable-width fonts  
here.) LaTeX ignores single newlines - it only cares about  
paragraphs. The line number issue (with compile messages) applies  
here, too.


>  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.

Lisp code should see whatever is in the original document. The  
semantics of the formalism used dictate the meaning of newlines. The  
original document, that is, the file, is relevant, because if in  
doubt, the lisp code should apply the same interpretation strategy to  
the code as the external tool will apply. For Python, for example,  
soft linefeeds don't matter because they won't appear in the file, so  
syntax coloring ought to ignore them. Hard linefeeds, however, do  
matter. I remember you made a change to the semantics of '.' in  
regexps to cover exactly that.
But what when lisp code doesn't use regexps to determine the extent  
of, say, a function block?

> 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 respect that opinion, and it's the right thing to do for plain  
text. But it doesn't work out for programming languages or other  
markup like LaTeX, and that happens to be where line numbers are  
actually used, at least in my daily work.

Maybe there is a justification for both modes of operandi, longlines  
and visual wrapping.

> 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.

Either way, that would be very good.


> 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.

Only when you want to enforce a maximum line length, which is  
something you must not do in Python and you don't need to do in LaTeX.

> 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 think there is a misunderstanding.
You seem to think that the alternative soft-wrapping method discussed  
actually enforces lines == paragraphs.
What I am suggesting is that the original representation in the file  
is respected. No conversion.

I am aware of the unwanted linebreaks introduced when you use visual  
wrapping together with a hard wrapped text file. Other editors do  
that, too, and it's not bad. It just means that one shouldn't mix the  
two editing modes.

If visual wrapping is used, it's exactly like the wrapping we have  
now - it just happens to occur at whitespace positions.
(And cursor up/down movements might be bound to something that is  
more useful.)