From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: User interaction from multiple threads Date: Sat, 18 Aug 2018 10:31:06 +0200 Message-ID: <5B77D94A.9000801@gmx.at> References: <838t59j821.fsf@gnu.org> <5B73DF10.5070200@gmx.at> <87muto5998.fsf@gmx.de> <5B73ED7E.5000102@gmx.at> <87in4b6hwf.fsf@gmx.de> <5B741C4E.6060403@gmx.at> <83sh3fin70.fsf@gnu.org> <5B756C41.1040600@gmx.at> <83a7pmifvd.fsf@gnu.org> <5B76782F.6060303@gmx.at> <83mutlh1s8.fsf@gnu.org> <5B7688AE.70205@gmx.at> <83h8jtgxwe.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1534580993 13526 195.159.176.226 (18 Aug 2018 08:29:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 18 Aug 2018 08:29:53 +0000 (UTC) Cc: michael.albinus@gmx.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 18 10:29:49 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 1fqwcH-0003P3-1k for ged-emacs-devel@m.gmane.org; Sat, 18 Aug 2018 10:29:49 +0200 Original-Received: from localhost ([::1]:38065 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqweL-00034q-Hu for ged-emacs-devel@m.gmane.org; Sat, 18 Aug 2018 04:31:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqwdg-00034a-2Z for emacs-devel@gnu.org; Sat, 18 Aug 2018 04:31:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fqwdf-0003kS-EN for emacs-devel@gnu.org; Sat, 18 Aug 2018 04:31:16 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:32787) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fqwdb-0003gu-EI; Sat, 18 Aug 2018 04:31:12 -0400 Original-Received: from [192.168.1.101] ([46.125.250.112]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lhfu5-1gCY1N1s3d-00mqJx; Sat, 18 Aug 2018 10:31:08 +0200 In-Reply-To: <83h8jtgxwe.fsf@gnu.org> X-Provags-ID: V03:K1:sJpc7JBq6gNQe+p13rawVQmr08Ve8DyZB0a5BM8aX41kiBREIX+ oaglsdkb6LeSyU1md9tOnFeved2yy7iQZyoiK+gJorVFa+zN/P9XRXKaeOTVmwAE0Zii4Y2 EedkOJCS4zf4lgyEkvczn9CFEEqn9ZlVrzcOg34BZ5iCF4eHVrXKkLJuW6R9YTHBR6xdqL1 4UaXLVeoYme4Zk9K46Cqg== X-UI-Out-Filterresults: notjunk:1;V01:K0:C9pgjoVLgFw=:p0biGBmVlXT+9TqMyIU8OW SHwhrhvF7QwEICjevdfC35aumGugpA2TARDBGELnJPEfnmpym37tPj8UDb57/XS5CsH+hu51c sKtxwCj/KistyN0aHi1DASCT7y5h54ATQS3r5xA0BDvLkUx7kqUffPLe5rrCSjPnbUMzfT74s h7c6eJIUn/kdNG2K/qAVF8JKbsk3iC7QK2eE8nu19r+g3HoOxsP+RLrMj3uCAzsvQrjNtGCu/ wUTZtE081QFj6uEMfRM4WJlfHOffDd9c/2V79A1cEu/1jnr7uhFcRiI0So9xVLqCa5Lrdufib BOgWq2ss05DiYU3ENy7lcmq3iC9cLVCHt95lYuRcDI0s+vlZe/9Nq73Vpe845/dhSDg1Md6Vi xSCjuPFroY7wrRrM4Qx19fVaN7+vQLVc79WiUYbhpUyRrjRFSLCU0qoQhEw85KNAQL9T787oG IWc8tRaAx4Cs0MVnXYKAaXLFko69fiF22Y949uPeijJwBFgAgsyioaXKfrIits2mtpdNgO4OP NusuCc7zdjvbuKTn+OmLkMPWn67I5jVDJLfRx78u1L5+P4UdzUIEZ1oqh+n32L3rG8hbQeyc+ IW2rRCFYSHJXMF84cxstyGLieSOebpYhzi2tC5luWMpyLoWsJvVIdyzwYvisoKVJ+4OZVgxoa UZGch7RyrEEM3K7RNgM3JVEy0nl/6GFYVilbV61LMYN1ILr7q5jaAlaudtKZMwkZhhHwnacaj 3qBOHG5r8pvfg5gK6RSFqBGSlnHpBCSkwGhD1EZ/KVya+bZw57L64WXCWkglGWyZXL4GWLHy X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.19 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:228654 Archived-At: > Tricky at best, IMO. Porting prompts from one frame's minibuffer window to another is just as tricky IMO. > Frame switch is just another input event. I > guess you are thinking about adding calls to thread-yield into input > processing code? When switching to a frame I would resume any pending input for the frame switched to. This has, a priori, nothing to do with threads. Input would be processed by the main thread as now. If a thread was blocked because it was waiting for input to complete, the main thread would send a 'thread-signal' to the blocked thread to unblock it as soon as input is complete. > Also, does it mean that every call to make-thread will now pop up a > new frame? When the thread requests it. The idea is that a user should not be pushed to react immediately to the prompt or information provided by the thread and that none of these get lost in the noise of other prompts and messages. Whether such frames are created when the thread is started or lazily when, for example, the question whether copying a file should overwrite an existing one with the same name arises, is left to the thread's writer. If a thread does not ask for its own frame, the main thread's mini-window will be used, possibly disrupting the user's workflow. > What will appear in the minibuffer window of the previously-selected > frame while we interact with another thread's frame? If the previously-selected frame was that of the main thread, whatever the main thread currently does. Though the main thread's mini-window would never show contents aimed for the mini-window of a separate thread provided that thread owns a frame. If the previously-selected frame was owned by a separate thread, it would show information pertaining to that thread and only to that thread. >> And reading a key sequence through the echo area is IIUC synchronous >> anyway so a user cannot practically switch frames during that. > > Are you sure they cannot switch frames in the middle of reading from > the minibuffer? You mean when SWITCH-FRAME-OK is set in 'read-key-sequence'? Maybe that would require special processing - I haven't looked into it. martin