From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Gemini Lasswell Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Sun, 19 Aug 2018 16:08:38 -0700 Message-ID: <87lg92q7ih.fsf@runbox.com> References: <838t59j821.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1534720034 1205 195.159.176.226 (19 Aug 2018 23:07:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 19 Aug 2018 23:07:14 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 20 01:07:10 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 1frWmp-00008U-0X for ged-emacs-devel@m.gmane.org; Mon, 20 Aug 2018 01:07:07 +0200 Original-Received: from localhost ([::1]:44391 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frWot-0003Lb-Os for ged-emacs-devel@m.gmane.org; Sun, 19 Aug 2018 19:09:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47285) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1frWoj-0003LL-KV for emacs-devel@gnu.org; Sun, 19 Aug 2018 19:09:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1frWof-00019f-5h for emacs-devel@gnu.org; Sun, 19 Aug 2018 19:09:05 -0400 Original-Received: from aibo.runbox.com ([91.220.196.211]:43814) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1frWoe-00018h-SA; Sun, 19 Aug 2018 19:09:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From; bh=fe9CfukjeaX65TauZbUhwRIsLiR5kNFIZ7gkzV4trkQ=; b=iho34zyavfU/dV14PjHWabUX30 vRE54bCOVtRu1a40D6gHUOiLQQwPwNJC0oySqbfVbLVPf470Wr9aWU8VQVxZkUQp8siD5xxwN+f5b DMrdPD8CYh0q5/YmDOVj5JM+gAJq8egDhayCy25Ng+1LG01+Ua4K/pF/cFB/o9CqZwyBlIieMebfM +mTIXtVaWZTJ59Sbr0njoxBUPoNBo2drUjnK0wOvGH68ZDJGSU0WXpcky9p/DvBGPuVDKcxwIR2Hj lx7eKc0kABWFvw9uHIzXwRhGuCJnFVQ/XeTrDWi1QpnI5jOZqmdv314XdbctFu9Y26EGSthmySJ+O mB94Q08Q==; Original-Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1frWoc-0005DY-Eu; Mon, 20 Aug 2018 01:08:58 +0200 Original-Received: by mailfront12.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1frWoL-0003j5-Em; Mon, 20 Aug 2018 01:08:42 +0200 In-Reply-To: <838t59j821.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 14 Aug 2018 18:12:54 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 91.220.196.211 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:228700 Archived-At: Hello, With the benefit of having read everyone else's suggestions to date, here are my answers to your use cases: Eli Zaretskii writes: > Use case #1: > > . 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 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. This means that a prompt from a non-main thread should become visible but not active, and the user should have to switch to the window containing it to respond. 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. The user shouldn't have to have a mental model of what threads are in order to work with Emacs, and the simpler we can keep the Lisp programmer's mental model of threads, the better off we will be. So those unrelated commands should be run in the main thread. 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. > Use case #2: > > 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? If > the latter, how do we indicate to the user that there is a prompt > from another thread? I don't think we should ever interrupt a key sequence. The prompting thread will have to wait. To indicate to the user that there is a waiting prompt, use a numeric indicator at the beginning of the echo area or upper left corner of the minibuffer, like the recursive minibuffer indicator. In a graphical environment a white number on a red ellipse would be a familiar clue to many users that there are messages waiting. > Use case #3: > > Similar, but now 2 or more non-main threads prompt the user, one > after the other, in quick succession. What should happen now, and > how will the user know there are multiple prompts? The first thread should get to show its prompt and wait for a response, and then show followup prompts if it can present them immediately after the first is answered. Other threads will block until the threads ahead of them are done prompting. The same numeric indicator as above could indicate to the user how many other prompts are waiting. A new keybinding could allow navigation forward and backward through the waiting prompts. (This is inspired by Martin's minibuffer list suggestion in http://lists.gnu.org/archive/html/emacs-devel/2018-08/msg00516.html) Another new keybinding might send keyboard-quit to all waiting prompts, which I would like to have available in the event that I do something that unexpectedly creates 250 of them.