Re: redisplay - very long lines

[Stefan Monnier]

>> This would only happen with truncated lines, not with wrapped
>> lines, right?
> If by ``wrapped lines'' you mean continuation lines, then (AFAIK) we

Yes, I meant "overly long, but not truncated".  Whether the wrapping is
done at a word boundary or at a char boundary shouldn't make much
difference in this respect.

> still need to walk to the end of a line before we are able to display
> it and all the lines after it.

In the above, when you say "line" do you mean "visual line" or "textual
line"?  IIUC we need to walk till the end of the visual line, but not
till the end of the textual line, so that shouldn't cause a slowdown
proportional to the length of the textual line.

>> [ Also, I'd much rather see occasional jumping than unbearably
>> slow display.  In many cases (e.g. unibyte fundamental-mode for binary
>> files), the likelihood of varying line height is pretty low. ]
> [How come you are suddenly in favor of unibyte operations?]

I'm not in favor of it, but binary files seem to be the most common
example of data where lines can grow to insane length.  And these are
better handled in unibyte buffers.

> FWIW, I think editing binary files other than via hexl is playing with
> fire, anyway.  But that's me.

Agreed, but if the file is sufficiently large (as is common for binary
files), hexl is impractical.


        Stefan