Re: Concurrency via isolated process/thread

[Ihor Radchenko <yantar92@posteo.net>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Do you know which particular parts of the global state are necessary for
>> redisplay? You mentioned current_frame and current_window. What else?
>
> You are asking questions that would require me to do a lot of code
> scanning and investigating to produce a full answer.  So please
> forgive me if I can afford only some random examples that pop up in my
> mind, not even close to the exhaustive list:

Thanks, that is good enough.
I mostly wanted to get pointers to interesting places in that 1.2Mb
xdisp.c file to save myself from reading it from top to bottom.

>   . the window tree (redisplay traverses it depth-first)
>   . point position of displayed buffers (needed to decide whether to
>     scroll the window)

Maybe point position in window?

>   . narrowing of each displayed buffer
>   . text properties and overlays of each displayed buffer
>   . which window is selected on each frame
>   . window-start position of each window
>   . variables affecting display: display-line-numbers,
>     show-trailing-whitespace, line-spacing, auto-compression-mode,
>     auto-hscroll-mode, mode-line-format, etc.

These lay in 4 categories:
1. Data attached to frame object (window tree)
2. Data attached to window object (point position, window-start, etc)
3. Data attached to buffer object (buffer-local variables, narrowing)
4. Global Lisp variables

I have a suspicion that at least windows in a frame might be redisplayed
in parallel, unless some strange Elisp code is allowed to modify things
affecting redisplay.

May I know what happens if redisplay code sets variables like
line-spacing or display-line-numbers? Is it allowed?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>