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

[Dmitry Gutov <dgutov@yandex.ru>]

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.