From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Mon, 20 Aug 2018 20:03:20 +0300 Message-ID: <83a7phdl7r.fsf@gnu.org> References: <838t59j821.fsf@gnu.org> <87lg92q7ih.fsf@runbox.com> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1534784494 19645 195.159.176.226 (20 Aug 2018 17:01:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Aug 2018 17:01:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: Gemini Lasswell Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 20 19:01:29 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1frnYX-0004v2-JS for ged-emacs-devel@m.gmane.org; Mon, 20 Aug 2018 19:01:29 +0200 Original-Received: from localhost ([::1]:48224 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frnaZ-0001R6-6m for ged-emacs-devel@m.gmane.org; Mon, 20 Aug 2018 13:03:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frnaS-0001Qo-FT for emacs-devel@gnu.org; Mon, 20 Aug 2018 13:03:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1frnaN-0002dA-JI for emacs-devel@gnu.org; Mon, 20 Aug 2018 13:03:28 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frnaN-0002d6-Fb; Mon, 20 Aug 2018 13:03:23 -0400 Original-Received: from [176.228.60.248] (port=2909 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1frnaN-0003wi-3B; Mon, 20 Aug 2018 13:03:23 -0400 In-reply-to: <87lg92q7ih.fsf@runbox.com> (message from Gemini Lasswell on Sun, 19 Aug 2018 16:08:38 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:228747 Archived-At: > From: Gemini Lasswell > Cc: emacs-devel@gnu.org > Date: Sun, 19 Aug 2018 16:08:38 -0700 > > Perhaps the way to accomplish this is to always read keyboard input in > the main thread. So when read-from-minibuffer, for example, is called > from a non-main thread, it would put the prompt on a queue for the main > thread to process, and then block until the response is ready. I have difficulty understanding how this "queue" model will work. Suppose the main thread has some way of figuring out when to show the first prompt on that "queue", then what? how (with what API) does it show the prompt, and how does it read the response? Remember: the prompting thread called some function, like read-file-name, and that function has its own ideas for how to interact with the user -- how will the prompting thread tell the main thread all those details? Some of the details reference variables that are local to the prompting thread's current-buffer, about which the main thread knows nothing. The main thread will need to thoroughly "emulate" the prompting thread to DTRT here. Then there's the issue of passing the result to the prompting thread. Unless you want to ask the programmer of that thread's function to write specialized code for user interaction, the prompting thread expects to get the keyboard input through the normal input machinery, like read_key_sequence. How will that be possible with the "queue" model? > If a user sees the cursor in a text buffer and types a character and > RET, that should never be interpreted as the response to a prompt that > appeared just as she started typing and which she didn't notice in time > to stop. What about input functions like read-char, which read a character without placing the cursor in the minibuffer? How will we ensure your principle above is honored? > The user should, as now, be able to type C-x C-o or C-x 5 o during > read-from-minibuffer, and perform unrelated commands on another buffer. This means some of the user input should go to the prompting thread, while some other part ("C-x C-o" in your example) should go to the main thread, so that it switches to another frame. How will Emacs know which part of user input is intended to what thread? Thanks.