Re: Inefficient redisplay

[Stefan Monnier]

>> >> This makes nhexl-mode completely unusable except on small buffers
>> > I suggest, first of all, to understand why the display engine misses
>> > the newlines you say you have in the before-strings.
>> Given my lack of understanding of the redisplay code, this is
>> more difficult.
> I could try, but is it possible to have a test case simpler than the
> whole package?  Something like one or two lines of text with whatever
> properties and overlays are needed to exhibit the problem?

I haven't gotten down to that yet.

> Also, what _is_ the problem, exactly?  Is that only that jit-lock
> misbehaves, or is there something else?  You said in your original
> mail that "redisplay code somehow seems to treat nhexl-mode's buffers
> as one single long-line", but what are the symptoms of this?

Several problems:
1- it seems that I'm not able to have position N displayed without
   having all positions 1..N with fontified set to non-nil (I.e. I have
   to have all the prefix of the buffer fontified).  That's a major
   problem since I use overlays: if N is large, that implies a large
   number of overlays, which implies serious performance problems.
2- performance sucks.  Maybe it's because of 1, but it's probably not
   only due to that, because performance is better when I go back to the
   beginning of the buffer (which doesn't remove overlays).

>> > The Emacs display code is known to behave very unfriendly when lines
>> > are too long, so my first advice would be not to do what hurts.
>> The buffer's actual text doesn't have long lines, and the display
>> doesn't have long lines either, so it really *should* work fine.
> The display engine does not see newlines that are covered by `display'
> properties and overlay strings, it sees the contents of the strings
> instead.  So if it _really_ misses the newlines in the
> `before-strings' you set up, it will behave as if the buffer had one
> long line.

The behavior I see seems consistent with a situation where the redisplay
"doesn't see" the newlines in the before-strings (although it does
display them correctly).

> The question is: how and why (and whether) does it miss those
> newlines.

Yes, we're still in the dark here.


        Stefan