Re: Inefficient redisplay

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Mon, 12 Apr 2010 15:28:22 -0400
> 
> And even if that had some impact, it wouldn't explain the behavior,
> since line-beginning-position works fine: it find the buffer's \n chars
> and stops there, oblivious to the fact that they have a `display'
> property which makes them appear differently.

Yes, right.  I was confused.

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

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?

> > 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 question is: how and why (and whether) does it miss those
newlines.