From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Wed, 29 Aug 2018 01:05:35 +1200 Message-ID: References: <838t59j821.fsf@gnu.org> <87lg92q7ih.fsf@runbox.com> <83a7phdl7r.fsf@gnu.org> <61492e7f622303d02405bedbe65fabae@webmail.orcon.net.nz> <83pnybdaer.fsf@gnu.org> <837ekicw7i.fsf@gnu.org> <877ekiierh.fsf@himinbjorg.adminart.net> <834lflb2fj.fsf@gnu.org> <83h8jk9l41.fsf@gnu.org> <8336v2994c.fsf@gnu.org> <83bm9q6x7v.fsf@gnu.org> <874lfi863s.fsf@himinbjorg.adminart.net> <83va7x5guc.fsf@gnu.org> <871sakl97g.fsf@himinbjorg.adminart.net> <8336uz6e8e.fsf@gnu.org> <877ekbego9.fsf@himinbjorg.adminart.net> <83mut73vau.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1535461736 11529 195.159.176.226 (28 Aug 2018 13:08:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Aug 2018 13:08:56 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Cc: hw , emacs-devel@gnu.org, rms@gnu.org, gazally@runbox.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 28 15:08:51 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 1fudjn-0002rF-9s for ged-emacs-devel@m.gmane.org; Tue, 28 Aug 2018 15:08:51 +0200 Original-Received: from localhost ([::1]:38137 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fudlt-0004hY-Bc for ged-emacs-devel@m.gmane.org; Tue, 28 Aug 2018 09:11:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fudgv-0007nX-Dh for emacs-devel@gnu.org; Tue, 28 Aug 2018 09:05:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fudgq-0008D8-FN for emacs-devel@gnu.org; Tue, 28 Aug 2018 09:05:53 -0400 Original-Received: from smtp-4.orcon.net.nz ([60.234.4.59]:48416) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fudgq-00086a-4Y; Tue, 28 Aug 2018 09:05:48 -0400 Original-Received: from [150.107.172.125] (port=7717 helo=[192.168.20.103]) by smtp-4.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1fudgd-0004RF-Kf; Wed, 29 Aug 2018 01:05:35 +1200 In-Reply-To: <83mut73vau.fsf@gnu.org> Content-Language: en-GB X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 60.234.4.59 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:229007 Archived-At: On 28/08/18 17:38, Eli Zaretskii wrote: > several minibuffers doesn't solve the basic problem, which is: how > should Emacs decide which of the threads' prompts gets submitted to > the user at any given time. When we solve that basic problem, we > could talk about the details like whether this happens in the same > minibuffer or in several. Backing up a little, the notion of multiple minibuffers seems like it could be relevant to the question of whether we are dealing with low-level user interactions, or with the higher-level functions used for asking the user questions. Is that still an open question? IIUC the main concern about dealing with user interaction at a low-level was the point about the prompt already having been generated by the time the interaction takes place. At face value, it seems to me that if we had per-thread minibuffers then perhaps that concern goes away? I.e. it wouldn't matter that a given thread had written a prompt to the minibuffer before the low-level interaction was requested, if the minibuffer it had written to wasn't being used by the main thread and/or other threads? (I do recall some earlier discussion about the possibility of thread- specific frames being created. I didn't understand the purpose of that at the time, but perhaps it was similar?) If handling the user interactions at a low level is desirable, and multiple minibuffers could enable that, then perhaps the practicality (or lack thereof, as the case may be) of thread-specific minibuffers is more than just a "detail", and might factor into the overall approach that is taken? -Phil