Re: redisplay system of emacs

[David Kastrup]

"alin.s" <address@hidden> writes:

> I did not want to state categorically that such or such solution is the good
> one.
>
> For example, if every emacs-window would be composed of lots of subwindows
> on server side, that lots of sub-windows could be completely hidden. Never
> use them to write something in them. They just report exactly the part of
> the buffer that should be redisplayed. They only catch and report events.
> They are invisible.
>
> Redisplay_internal does lots and lots of computations to detect which
> part of the buffer should be redisplayed at a given moment.

By checking which on-screen parts have changed how.

> All these computations can be avoided using a system of subwindows (1
> for every char).

That is nonsense.  One then has to check which subwindows need to be
moved/replaced as a result of buffer changes.  The X server has no clue
about buffers and the display matrix and its relative arrangement.

> That was my idea: to replace redisplay_internal with something simple
> and efficient. Something simple and efficient is to keep in the emacs
> a vector of little windows, and to register in the server all these
> windows.

And the server works by magic?  Unlikely.  Even if the scheme were not
unfeasible.

> The structure of windows is changed only when configure event is
> caught or when one changes the font, or split windows, etc. So very
> rarely.

Every insertion of a single character of a proportional font will change
the "windows" layout.

> 95% of the operations of redisplay can be covered with the system of
> little windows registered in the server. No more need of
> redisplay_internal for X.

I think you have the wrong idea about what redisplay_internal does, and
what an X server can do on its own.

-- 
David Kastrup