Re: Inefficient redisplay

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> One related problem (which can be witnessed firsthand from Elisp) is
>> that all the text between point-min and the window's point is jit-locked
>> (even though only the text visible in the window should need to be
>> jit-locked).

> I believe this is because of the following heuristics in jit-lock.el:

> 	   ;; Decide which range of text should be fontified.
> 	   ;; The problem is that START and NEXT may be in the
> 	   ;; middle of something matched by a font-lock regexp.
> 	   ;; Until someone has a better idea, let's start
> 	   ;; at the start of the line containing START and
> 	   ;; stop at the start of the line following NEXT.
> 	   (goto-char next)  (setq next (line-beginning-position 2))
> 	   (goto-char start) (setq start (line-beginning-position))

No, the trace I showed was for jit-lock-function which comes before this
piece of code (jit-lock-function calls jit-lock-fontify-now).

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.

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

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

And of course there isn't much I can do about it: the whole point of the
exercise is to make a hexl-mode variant which works only by modifying
the display but not the buffer's text (so it doesn't mess with the
undo-list, etc...).


        Stefan