Re: relative line numbers and folding: how to make they play along?

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

>> >> Actually, I don't think there needs to be flickering if the first step
>> >> ("perform redisplay of window") just computes the new matrices without
>> >> performing any drawing.
>> > Since the display engine computes the number of each screen line as it
>> > lays them out, I don't understand why would 2 phases be needed.  I'm
>> > probably missing something.
>> If we bake it into the redisplay code, we can indeed do it "on the fly",
>> but if we want this feature to be implemented in Elisp it seems a lot
>> more tricky to avoid the 2 passes.
> But this sub-thread started with you talking about baking it into
> redisplay:

By "help from the display engine" I meant that we'd need to make
changes to the C code, but I didn't mean to bake it in.

> These two passes are described in terms of what redisplay does, they
> are not visible to Lisp: we don't return to the command loop after
> each window's redisplay, and the glyph matrices are not exposed to
> Lisp, either.

I didn't mean to return to the command-loop in-between.

I was more thinking of the situation I mentioned in some other
discussion: rewrite the top-level of the redisplay code in Elisp,
basically a function which:
- asks the C code which windows need to be redisplayed.
- call a C function on each of those windows to recompute the matrices.
- detect the case where point is out of the window, and either move
  point and call the recompute-matrices function, or call another
  C function to do the scrolling.
- then call a C function on each window/frame to update the display.

From there we can hope to provide a more efficient/robust follow-mode
(while still implementing it in Elisp).  And in that context, we should
also be able to provide a more efficient relative-visual-linum-mode, tho
it might require yet more access, such as subrs to scan/read the
matrices, and maybe other subrs to modify the matrices (to update the
margin).

Some of those primitives would probably also be useful in order to write
tests of the redisplay code.

I think such a change should be doable without a complete rewrite of
the redisplay.  But it would undoubtedly take a fair bit of work.


        Stefan