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: Fri, 24 Aug 2018 10:34:07 +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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1535063638 4201 195.159.176.226 (23 Aug 2018 22:33:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 23 Aug 2018 22:33:58 +0000 (UTC) User-Agent: Orcon Webmail Cc: gazally@runbox.com, hw@adminart.net, rms@gnu.org, emacs-devel-bounces+psainty=orcon.net.nz@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 24 00:33:54 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 1fsyAs-0000zZ-1Q for ged-emacs-devel@m.gmane.org; Fri, 24 Aug 2018 00:33:54 +0200 Original-Received: from localhost ([::1]:39076 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsyCy-0001l8-G0 for ged-emacs-devel@m.gmane.org; Thu, 23 Aug 2018 18:36:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsyBI-0000F2-8v for emacs-devel@gnu.org; Thu, 23 Aug 2018 18:34:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fsyBH-0003sZ-FR for emacs-devel@gnu.org; Thu, 23 Aug 2018 18:34:20 -0400 Original-Received: from smtp-3.orcon.net.nz ([60.234.4.44]:34554) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fsyBC-0003pE-ME; Thu, 23 Aug 2018 18:34:14 -0400 Original-Received: from [10.253.37.70] (port=44086 helo=webmail.orcon.net.nz) by smtp-3.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1fsyB5-0005xV-NR; Fri, 24 Aug 2018 10:34:08 +1200 Original-Received: from wlgwil-nat-office.catalyst.net.nz ([202.78.240.7]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Fri, 24 Aug 2018 10:34:07 +1200 In-Reply-To: <834lflb2fj.fsf@gnu.org> X-Sender: psainty@orcon.net.nz X-GeoIP: -- 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.44 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:228857 Archived-At: On 2018-08-24 02:08, Eli Zaretskii wrote: >> From: Richard Stallman >> Perhaps the minibuffer should indicate which thread is making the >> request when that isn't the current thread. > > Why is that important? Because otherwise it won't necessarily be obvious to the user that a succession of prompts are unrelated? They may or may not be able to figure it out relatively easily, but that depends somewhat on how the specific prompts in question happen to have been written. Some kind of identifier for the source of the message seems very sensible to me. If nothing else, it immediately tells the user that the question they are being asked *may* not be related to the thing they were just doing, which I think is a useful piece of information to lead with, as it prevents the confusion before it can occur. > Wouldn't the prompt itself be informative enough? Undoubtedly that would often be true, but are all prompts written in such a specific fashion to guarantee they would be unambiguous within any arbitrary arrangement of asynchronous prompting activity? I would be very surprised if that turned out to be true. At minimum, few if any of the existing prompts (many of which may now be triggered in thread contexts), will have been written with this particular scenario in mind. > And how (in what terms) would you suggest to indicate the thread ID > in this case? `make-thread' takes an optional NAME argument, so perhaps that can be used when it's set? Otherwise some kind of internal ID would probably have to suffice? If NAME is not generally suitable, then perhaps we need something additional as a human-readable identifier? -Phil