emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concurrency via isolated process/thread


From: Eli Zaretskii
Subject: Re: Concurrency via isolated process/thread
Date: Mon, 10 Jul 2023 19:03:03 +0300

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: monnier@iro.umontreal.ca, luangruo@yahoo.com, emacs-devel@gnu.org
> Date: Mon, 10 Jul 2023 14:55:36 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.

You'd still need to do that, because the list I posted is nowhere near
complete.

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

No, point of the buffer.  We copy the window-point to the buffer point
once, but assume it stays put thereafter, until we are done with the
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

Beware: you categorize and are making conclusions based on incomplete
information.

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

Mostly, yes.  But there are things like resize-mini-windows that can
affect other windows.  Also, this is limited to GUI redisplay; TTY
frames have additional subtleties.

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

In a nutshell, we need to abort the current redisplay cycle and start
anew.  So doing that is a very bad idea.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]