Re: [External] : Re: Would you say this information window is well designed?

[Dmitry Gutov]

On 23.02.2021 20:26, Eli Zaretskii wrote:
> > Date: Tue, 23 Feb 2021 17:59:08 +0000
> > From: Peter Dean <laszlomail@protonmail.com>
> > Cc: "drew.adams@oracle.com" <drew.adams@oracle.com>, "stefankangas@gmail.com" <stefankangas@gmail.com>, 
> > "larsi@gnus.org" <larsi@gnus.org>, "dgutov@yandex.ru" <dgutov@yandex.ru>, "emacs-devel@gnu.org" 
> > <emacs-devel@gnu.org>
> >
> > Then there could be a refresh rate value (e.g. 15 ms or some other value,
> > configurable) and thread-yield could check if the main thread got the lock
> > within this time window.
> >
> > If not then it would give the lock explicitly to the main thread, otherwise
> > the next thread gets the lock.
>
> thread-yield runs in the context of the thread that yields.  You make
> it sound like there's some entity other than the involved threads
> which runs thread-yield, but that's not what happens.

It was also my impression that the threading facility in Emacs is 
incomplete.

For one thing, error handling is very low-level (saving only the last 
error looks like a straight translation from C).

Another: there is no 'thread-resume' which some came to expect from 
other languages. Examples:

https://ruby-doc.org/core-2.5.0/Fiber.html#method-i-resume
https://github.com/laverdet/node-fibers ("run() will start execution of 
this Fiber, or if it is currently yielding
 * it will resume execution")

But it seems we can substitute with condition-wait (in the worker 
thread) + condition-notify (in an idle timer which it would create 
before waiting). That should help suspend-resume the worker thread on a 
regular basis, all the while giving the main thread the time to do its 
thing.

Either way, I don't think this can solve the original issue. Having a 
link appear only some time after a Help buffer is shown is not a great 
experience either: blinking elements are a visual nuisance. So if we 
could pre-index the manual for symbols, that would be preferable.