Re: Line wrapping during redisplay

[Kim F. Storm]

"Richard M. Stallman" <address@hidden> writes:

>     Perhaps you would like to experiment a little with the following patch
>     which implements non-destructive line-wrapping during redisplay, i.e.
>     it automatically breaks _displayed_ lines at suitable spaces and tabs.
>
> With this approach, the commands that operate on lines in the buffer
> will all treat the paragraph as one line, even though it appears as
> several.  That is extremely inconvenient.  There is a package that
> redefines the most common commands, but there are others, including
> M-x occur.  User programs also look at lines.

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.

So although it is not useful for line wrapping in general, 
perhaps it could be useful for a nicer way to handle continued lines.

For example, we could have a setting wrap-column = t which means
to use the actual width of the window for wrapping -- to get the
effect of continuation lines, but with a "human touch" to where 
redisplay actually breaks continued lines.

I don't claim that the wrap-column functionality would replace any
of the existing packages -- but it may be useful for some things...

>
> I strongly prefer the approach in longlines.el, because the line
> breaks are there in the buffer, so that all sorts of commands that
> look for line breaks will see them where the user sees them.

I am not against the approach of longlines -- if it can be fixed to
work with proportional-width fonts, images, overlays, etc.

But IIRC longlines also has some problems with line movement -- wasn't
that what longlines-2 should fix ... ?

>
> Here's a peculiar idea.  Make it possible for an overlay to make a
> space "appear" as a newline or vice versa.  The result is a change in
> the apparent contents of the buffer, for display purposes and for some
> commands.  But killing and yanking would not copy these overlays
> (since they don't copy any overlays).

Would it have the same problems with line movement being out of sync
with what's displayed in the window...

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