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: Sat, 25 Aug 2018 22:32:01 +1200 Message-ID: <5e769fa4-9994-8e90-516b-9b76cd714d38@orcon.net.nz> 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> 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 1535193061 27383 195.159.176.226 (25 Aug 2018 10:31:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Aug 2018 10:31:01 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 Cc: hw@adminart.net, emacs-devel@gnu.org, emacs-devel-bounces+psainty=orcon.net.nz@gnu.org, gazally@runbox.com To: Eli Zaretskii , rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 25 12:30:57 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 1ftVqK-00070i-AW for ged-emacs-devel@m.gmane.org; Sat, 25 Aug 2018 12:30:56 +0200 Original-Received: from localhost ([::1]:45274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftVsQ-0002uU-FQ for ged-emacs-devel@m.gmane.org; Sat, 25 Aug 2018 06:33:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftVrf-0002l0-EE for emacs-devel@gnu.org; Sat, 25 Aug 2018 06:32:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ftVra-0004ER-C2 for emacs-devel@gnu.org; Sat, 25 Aug 2018 06:32:19 -0400 Original-Received: from smtp-1.orcon.net.nz ([60.234.4.34]:42180) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ftVra-0004Ay-0Q; Sat, 25 Aug 2018 06:32:14 -0400 Original-Received: from [150.107.172.72] (port=62011 helo=[192.168.20.103]) by smtp-1.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1ftVrN-0000gL-V5; Sat, 25 Aug 2018 22:32:02 +1200 In-Reply-To: <8336v2994c.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.34 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:228894 Archived-At: On 25/08/18 19:51, Eli Zaretskii wrote: > I'm saying that fixing the prompt itself is a better alternative, > because we will always give the prompt more screen estate than to > the thread ID. I'm a big fan of how eldoc support was added to `eval-expression' such that when you enter elisp into the minibuffer, the mode line is used to display the eldoc information. It occurs to me that a similar thing could be done to display the thread identifiers for prompts without taking real-estate away from the prompt itself, by placing that contextual information in the mode line. This would mean that the thread identifier does not appear to be a part of the prompt itself (which I think is good, because it's not actually part of the prompt, but rather the context in which the prompt is happening). This should also help alleviate related concerns about the thread identifiers needing to be exceptionally short. Perhaps this approach to the idea makes it more appealing? > Also, the thread ID is fixed for each thread, whereas we > could add different text to each prompt to make each one more > self-describing. > > But in general, I see no significant difference between these > two alternatives, because they both add some text to the prompt. Personally I feel the differences are significant because they're each adding distinctly different text. The thread identifier/context is adding text which the prompt is incapable of adding for itself, because it has no knowledge of whether or not it is being executed in the main thread or not. That aside, it also provides an indicator to the user that the prompt in question has been triggered by asynchronous activity, which I think would be helpful information even *without* a specific ID. Adding a thread identifier and improving the prompt text also don't seem to me like mutually exclusive enhancements. If a given prompt can be clarified without it seeming excessive in synchronous situations, that's still a good improvement even when a thread identifier is also present. -Phil