From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: hw Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Sun, 26 Aug 2018 14:52:41 +0200 Organization: my virtual residence Message-ID: <874lfi863s.fsf@himinbjorg.adminart.net> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1535288728 26454 195.159.176.226 (26 Aug 2018 13:05:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Aug 2018 13:05:28 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cc: psainty@orcon.net.nz, gazally@runbox.com, 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 Sun Aug 26 15:05:24 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 1ftujL-0006lJ-CH for ged-emacs-devel@m.gmane.org; Sun, 26 Aug 2018 15:05:23 +0200 Original-Received: from localhost ([::1]:49089 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftulR-0007V0-MM for ged-emacs-devel@m.gmane.org; Sun, 26 Aug 2018 09:07:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftul9-0007Rh-4a for emacs-devel@gnu.org; Sun, 26 Aug 2018 09:07:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ftul7-0006KP-9h for emacs-devel@gnu.org; Sun, 26 Aug 2018 09:07:13 -0400 Original-Received: from mo6-p01-ob.smtp.rzone.de ([2a01:238:20a:202:5301::11]:36643) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ftul2-0006DO-F1; Sun, 26 Aug 2018 09:07:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1535288827; s=strato-dkim-0002; d=adminart.net; h=Sender:References:Message-ID:Date:In-Reply-To:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=bbdDgqnuD6BggAVXWCnP4Pp1Lwaz8SPkNQBRcUvdTfI=; b=MEGmmERRLE1c7mkkH5Mw8IDwEZBZ80zivkmROiNMS28xWIjpTrBkYbfdvFbMZrWpuW ZAIEwbvYfVYWer1WY4R7APH6E78yRSPT+wfUzk1Vxfn4Pp1Us3KHfqJLjJftU/tAZcFV Jip2PeDHpcw57XjedU8IJ9K3W+2xmmT3Q0/U/s6yYK4A+kHwLFXIa14FxtlqfyLXkl2R ffH8hNp/e5xMSMTJpIgA+gAPZ9GJTYTuBb9etb95e4b+3/x5upLH3uS46zRig9PV5d0N /F3jeSFdWgAC64m6RXD+cL+PHyRK1jbiF2tCtNI4J5EWtPP/TRelypEc+DzgewgrQDWO yGuw== X-RZG-AUTH: ":O2kGeEG7b/pS1FS4THaxjVF9w0vVgfQ9xGcjwO5WMRo5c+h5ceMqQWZ3yrBp+AVdIIwXjneEe9k=" X-RZG-CLASS-ID: mo00 Original-Received: from lee by himinbjorg.adminart.net with local (Exim 4.90_1) (envelope-from ) id 1ftukp-0000Rx-W3; Sun, 26 Aug 2018 15:06:55 +0200 In-Reply-To: <83bm9q6x7v.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 25 Aug 2018 22:51:48 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5301::11 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:228925 Archived-At: Eli Zaretskii writes: > [...] >>=20 >> Emacs could add the thread ID at the start of a prompt >> when there are multiple threads that could be asking for input, >> such that there is a possibility of confusion. >>=20 >> That could avoid lengthening the prompts in the usual cases. > > I don't see how this would solve the problem, since thread IDs will > always be quite short. I don=C2=B4t understand this. I thought requests for input would be queued in such a way that the users can look at the queue when ever they see fit, and the information in the queue along with the prompts would make it obvious to the users what each request is about. Wouldn't that be much better than having requests for input and the threads that created them fight over the mini-buffer and interrupt the user once they can hijack the mini-buffer?