emacs-devel
[Top][All Lists]
Advanced

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

Re: save-excursion and multi-thread?


From: Eli Zaretskii
Subject: Re: save-excursion and multi-thread?
Date: Mon, 27 Sep 2021 13:13:08 +0300

> From: Qiantan Hong <qhong@mit.edu>
> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Mon, 27 Sep 2021 06:14:58 +0000
> 
> > IOW, it sounds to me like you need to suspend the execution of the
> > command until the client answers the question, and you already have
> > the machinery to handle bidirectional communications between the
> > client and the server, so just reuse it for asking a question and
> > receiving the response, before you perform the command.  Am I missing
> > something?
> Exactly, however I want the machinery to work for ordinary Emacs “stock” 
> commands with minimal effort.
> 
> Suppose we opt to rewrite any Emacs command that would be remote-called,
> then of course it’s easy to rewrite them so that they immediately return
> when they originally READ-FROM-MINIBUFFER while pushing the rest
> of the original command as a continuation on some queue 
> (this is in fact just a CPS transform). 
> The filter function will then execute continuations on the queue upon
> receiving response.
> 
> We still need to deal with restoring point/mark/etc when switching 
> continuation
> (i.e. we need to save state when the command “immediately return” and
> restore state when we run the continuation on the queue), but it’s well in our
> control and doable.
> 
> However I want to use original commands without modification if possible.

I see your point and your motivation.  However, I don't think that
using threads will make your job any easier.  Threads that run
interactive code (i.e. code that needs to interact with the user and
perform any form of redisplay) are not easy to get working right, and
in fact I'm not aware of any code which accomplishes that.

So I suggest using the "hard way", without threads, as I think it will
eventually turn out to be simpler and less tricky for you to get
right, let alone won't need any changes to Emacs.



reply via email to

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