bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kill


From: Eli Zaretskii
Subject: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs
Date: Fri, 31 Aug 2018 09:52:19 +0300

> From: Gemini Lasswell <address@hidden>
> Cc: Eli Zaretskii <address@hidden>,  address@hidden
> Date: Thu, 30 Aug 2018 12:29:44 -0700
> 
> I don't understand why this is so complicated.  Why not just have the
> thread show a message, instead of having it send a signal which gets
> translated into an event that makes the main thread show a message?

Because the echo area could be showing something important from the
main (or some other) thread, e.g. if the user typed "C-x C-f", but
didn't yet finish responding to the request for the file name.
Displaying something from another thread will wipe out that
interaction's text.

By submitting an event to the main thread, we make sure these two
interactions will be serialized.

> Also, if we eventually implement one of the proposals in emacs-devel to
> allow threads other than the main one to accept keyboard input, then
> there would be no guarantee that putting the event in the keyboard
> buffer would get it to the main thread.

I don't think it matters, because it will get to the thread which is
reading input events, and that thread will then act on the event.  But
if it turns out it does matter, we can always tag each even with its
target thread or something, and modify the queue handling to only act
on events whose target is the current thread.





reply via email to

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