bug#45898: 27.1; wedged in redisplay again

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3702 bytes --]



> On 2022-06-24,, at 9:57 , Eli Zaretskii <eliz@gnu.org> wrote:
> 
> 
> Gerd, your comments will be most appreciated, TIA.
> 

I didn’t read the whole thread in the bug report, but i think I understand the gist of the matter, from our recent conversation, and from reading the change set. 

I think it helps me in the following when I briefly describe the model of Emacs’ internals I have in my head.  That way, I can write about things in terms in which I think.  So, let me try.  When I think of Emacs' design, I think of functions and categories they belong to.  Categories in the sense of animal, dog, human, plant.   A bit like modules, but not quite, but if it’s helpful, just think of modules instead. 

The categories I'd like to use here, are lisp, redisplay, iterator, update, regexp.   I leave the rest out. Here is what I group under these categories:

Lisp
	Eval, funcall
	API for buffers, windows, etc
	...
Iterator
	Walk over text in display order (including  bidi, display strings)
	Determine current character, image
	Keep track of pixel (x y w h)
	(x y) <-> text position computation
Redisplay
	Produce desired glyphs 
	Produce as few as possible (optimizations)
Update
	Bring desired glyphs to the screen
Regexp 
	Matching and searching support

That’s why I’m sometimes slow when redisplay is used for what I call iterator. 
If -> denotes "uses", or "calls into", we have

Lisp 
	-> iterator in (x y) <-> text pos 
	-> regexp 
	-> redisplay (I think, Fredisplay?)
Redisplay 
	-> iterator 
	-> lisp (hooks)
Iterator
	-> Lisp (eval funcall hooks)
Update 
	-> maybe hook, I don’t remember
Regexp 
	-> lisp, I’ve heard

Very roughly, and much too long, sorry for that.

What I so far understand about your design, and i haven't looked at details:

One of the first things that came to my mind is a new category "time fuse" (in German Zeitzünder), something counting ticks, and detonating (signaling) at some point.  I admit that I find the names you used with redisplay in them confusing.  Especially in the regexp code and so.

Functionality-wise, Iterator now signals an error that redisplay catches. 

The error is signaled when a global tick counter exceeds a max value.  Each movement of an iterator increments the global tick counter.  The counter is global because you want to sum up all the ticks that occur between a given start point where the tick counter is set to 0, and the point where the ticks exceed the maximum, regardless of iterator -> lisp -> iterator nesting.

The global tick counter is also incremented from regexp.  I think font-lock plays a role here.  One scenario is redisplay or lisp -> iterator, iterator needs font-lock to run (-> lisp), font-lock matches a regexp (lisp -> regexp), and we get stuck on a long line.  Likewise with other stuff, like syntax.

Good.

(BTW, the call to update the tick in regexp can lead to a GC when the error is signaled, in the same way as in bug 56108 with maybe_quit.  So we might need that, too.)

Maybe we could disable the calls cheaply when max-ticks is 0?  I mean, something that inlines

	if (max_ticks > 0)
          update_ticks(...)

I would have a better gut feeling in that case, wrt older machines.  Not that I notice a slowdown on my machine, but I'm building with ASan enabled, so everything is kinda slow anyway.

The meaning of display_working_on_window_p is not clear to me.  I see what setting it does in the end, but I can't tell what this means:

/* True while some display-engine code is working on layout of some
   window.

Probably good.

Do you want me to take a deeper look at specific places?



[-- Attachment #2: Type: text/html, Size: 16221 bytes --]