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: Tue, 28 Aug 2018 19:50:06 +0300 Message-ID: <831sai4erl.fsf@gnu.org> 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 X-Trace: blaine.gmane.org 1535474921 30069 195.159.176.226 (28 Aug 2018 16:48:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Aug 2018 16:48:41 +0000 (UTC) Cc: hw@adminart.net, emacs-devel@gnu.org, rms@gnu.org, gazally@runbox.com To: Phil Sainty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 28 18:48:37 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 1fuhAS-0007gw-KV for ged-emacs-devel@m.gmane.org; Tue, 28 Aug 2018 18:48:36 +0200 Original-Received: from localhost ([::1]:39044 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuhCY-0006W4-Rq for ged-emacs-devel@m.gmane.org; Tue, 28 Aug 2018 12:50:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54388) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuhCB-0006Q5-Sb for emacs-devel@gnu.org; Tue, 28 Aug 2018 12:50:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fuhCA-0005qc-AH for emacs-devel@gnu.org; Tue, 28 Aug 2018 12:50:23 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuhC6-0005me-FO; Tue, 28 Aug 2018 12:50:20 -0400 Original-Received: from [176.228.60.248] (port=3488 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fuhBz-0006sa-8y; Tue, 28 Aug 2018 12:50:12 -0400 In-reply-to: (message from Phil Sainty on Wed, 29 Aug 2018 01:05:35 +1200) 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:229020 Archived-At: > Cc: hw , gazally@runbox.com, rms@gnu.org, emacs-devel@gnu.org > From: Phil Sainty > Date: Wed, 29 Aug 2018 01:05:35 +1200 > > 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? It certainly is, because when Emacs is idle at top level, and waiting for the user to type the next command, the minibuffer is implicitly taken, but without any function like read-from-minibuffer being called. So we still need some way of telling the main thread to stop waiting and yield the minibuffer. > 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. That was one concern. The other is what I described above. > At face value, it seems to me that if we had per-thread minibuffers > then perhaps that concern goes away? Not entirely, because there's still a problem of how and when to display the relevant minibuffer in the echo area. And the issue with directing the input the user types to the right thread also stays.