[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: User interaction from multiple threads
From: |
Eli Zaretskii |
Subject: |
Re: User interaction from multiple threads |
Date: |
Wed, 15 Aug 2018 19:47:06 +0300 |
> Date: Wed, 15 Aug 2018 10:06:40 +0200
> From: martin rudalics <address@hidden>
>
> > . The main thread is waiting for user input. The user didn't yet
> > type anything
> > . A non-main thread runs Lisp that prompts the user for some input
> >
> > In this case, we probably want the following input to go to the
> > prompting thread, right? But it might also be the case that the
> > user actually wants the input to go to the main thread, e.g. to
> > perform some unrelated command. Should we allow that? If yes, how
> > should Emacs know which thread should receive what the user types?
>
> If we make a rule that each thread owns a frame with a minibuffer, the
> decision which thread receives input on a GUI is left to the windowing
> subsystem.
As you well know, when the user switches to another frame, we
redisplay the mini-window on the newly selected frame to display the
same prompt/echo there as was displayed on the previous selected
frame. So what you suggest won't work without very serious surgery to
our handling of the mini-window (which is already quite complex and
fragile).
> We would have to emulate that behavior on a TTY somehow
> but that should be an implentational detail.
And that is another complication, of course.
I think that at least at first we should go for some kind of
serialization of using the mini-window, because having several ones
active at the same time is a much harder trick to pull.
> > Same as the previous, but now the user is in the middle of typing a
> > key sequence, when the non-main thread prompts. For example,
> > suppose the user has typed "C-x".
> >
> > What do we want to happen now? Do we "preempt" the main thread and
> > let the following input to go to the prompting thread? Or do we let
> > the prompting thread wait until the main thread reads a full key
> > sequence and runs the command bound to it? If the former, what to
> > do with the partial key sequence ("C-x") that the user typed?
>
> The partial key sequence should be preserved and typing resumed where
> it was interrupted when the user switches back to the main thread by
> selecting a frame owned by the main frame.
Would be nice, I agree, but again probably not quite simple.
- Re: User interaction from multiple threads, (continued)
- Re: User interaction from multiple threads, Eli Zaretskii, 2018/08/16
- Re: User interaction from multiple threads, martin rudalics, 2018/08/17
- Re: User interaction from multiple threads, Eli Zaretskii, 2018/08/17
- Re: User interaction from multiple threads, martin rudalics, 2018/08/17
- Re: User interaction from multiple threads, Eric Abrahamsen, 2018/08/17
- Re: User interaction from multiple threads, Michael Albinus, 2018/08/17
- Re: User interaction from multiple threads, Eli Zaretskii, 2018/08/17
- Re: User interaction from multiple threads, martin rudalics, 2018/08/18
- Re: User interaction from multiple threads, Eli Zaretskii, 2018/08/18
- Re: User interaction from multiple threads, martin rudalics, 2018/08/19
- Re: User interaction from multiple threads,
Eli Zaretskii <=
- Re: User interaction from multiple threads, martin rudalics, 2018/08/16
- Re: User interaction from multiple threads, Eli Zaretskii, 2018/08/16
- Re: User interaction from multiple threads, Michael Albinus, 2018/08/16
- Re: User interaction from multiple threads, Gemini Lasswell, 2018/08/20
- Re: User interaction from multiple threads, Eli Zaretskii, 2018/08/20
- Re: User interaction from multiple threads, Gemini Lasswell, 2018/08/19