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: Thu, 16 Aug 2018 14:20:58 +0200 Message-ID: <5B756C2A.4020706@gmx.at> References: <838t59j821.fsf@gnu.org> <5B73DF10.5070200@gmx.at> <83tvnvinlh.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 1534422036 17215 195.159.176.226 (16 Aug 2018 12:20:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 16 Aug 2018 12:20:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 16 14:20:32 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 1fqHGR-0004Kh-De for ged-emacs-devel@m.gmane.org; Thu, 16 Aug 2018 14:20:31 +0200 Original-Received: from localhost ([::1]:55280 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqHIW-0001NG-76 for ged-emacs-devel@m.gmane.org; Thu, 16 Aug 2018 08:22:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39918) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fqHHN-0001Lr-S1 for emacs-devel@gnu.org; Thu, 16 Aug 2018 08:21:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fqHHG-0001qW-Fl for emacs-devel@gnu.org; Thu, 16 Aug 2018 08:21:29 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:57017) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fqHH7-0001l2-M5; Thu, 16 Aug 2018 08:21:16 -0400 Original-Received: from [192.168.1.100] ([46.125.249.92]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LZlZ2-1gHrmj0UHM-00lWWB; Thu, 16 Aug 2018 14:21:09 +0200 In-Reply-To: <83tvnvinlh.fsf@gnu.org> X-Provags-ID: V03:K1:+rd5DhHOulLowvs1RkpGhH2rIacicx5k/15mPxXE0uo/+isEUku 9RYDADWfFcXDDDFDB0Ln1iLrMFKy2mXu2T4RBBb9FydTBaWoGqnTt/oACIkzWP6UuoLBG+0 XwWlPB+KypzawYgwgAR5O0xqK0VdlHDxUl5BE4AhUzdtQdMF4MJsGMUYK3Xt0Da1wqfHXdL 4ldJqAv9GyuFAPLmcsKxA== X-UI-Out-Filterresults: notjunk:1;V01:K0:XBa0WNCngsw=:iPsixtsXCUd7E977rJrMiO YmASum0Stn1SNgcArTAlxP8sNe9E55LwprNby43UoocSXtZ20EEE1lsGETYB7WHw3yPm++0Ol aQLzP0RsKn38XeSw7lN1j5dA4Pnzoze/EQVLZb3Wae/HuFIT/nRyP+s0zGUWY1Lsj0bxXPKHm gwef/wZvq9BlzKjeukIY///3eO7eLNZMiLoaTvOVgkx8M64YXhsaNLSepn/pV0uhuXFj2T7bJ 6seJm5QnA0JUOlKDaVxD7oLvcLJdHJbvu02xhBoy9uYuiQHDYGr2Tr9OIRIsDW/balmOnCnQj 59C1AfXRLpmmADfl03ISi/KXNeEPwIPPuIDSsQX/DUggVqlo3gpU1xihEDrXUCH+92Gg8Hh42 UVdRx/0lDHNGPiahDAbT5E4aUDd8hegiCpWssBwADD90O2jtohEA6z2p9dW5UOd4FhX2qPWob fhCk2BJYIDLxQWDeTWkkCnXOa/Gb7Sw/7F0Az//rQUUEQcxGCbX3EjWv70+lmpi9rMSRYWMfH y6V7rFb8fms5BBZAfhpXUlwC8UMSk8YPfFLsYtDTD2S+7xV5VguevJixpxleSbN8pQvLE4IMj 1ldNZLEjUOBZ4QUU4lCPL+7yGrUpjqcr+kKGlD815wQn90Bs4AlCXVFB/Z7tAr0fRS9JDx3RS k7uDGAwxQ6TKHGEVkeq7UWa8M7nxbS42UEa1436GQXBjx/T05cE20mR4g+CId1MBkJ5u/2qUd heu5mNx4t/hRlF/4BrdFFXAv4hUZuzbBejHCLKk+owrjjGiCcEV6hoDDk1Yk2xyp3uHxQvz9 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.22 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:228586 Archived-At: > As you well know, when the user switches to another frame, we > redisplay the mini-window on the newly selected frame to display the > same prompt/echo there as was displayed on the previous selected > frame. So what you suggest won't work without very serious surgery to > our handling of the mini-window (which is already quite complex and > fragile). Agreed when I think of extravaganzas like 'yes-or-no-p' calling 'read-from-minibuffer' and prompting in the minibuffer and 'y-or-n-p' calling 'read-key-sequence' and prompting in the echo area and using 'cursor-in-echo-area' to make one virtually look like the other. But in this thread you wanted to "first pay attention to conceptual issues related to this, before we start talking about implementation" and that's what I've tried to do. > I think that at least at first we should go for some kind of > serialization of using the mini-window, because having several ones > active at the same time is a much harder trick to pull. Isn't serialization the hard trick we're pulling ever since? How to maintain the order and duration of objects appearing in the mini-window, how to avoid that tooltip or eldoc text shadows whatever goes in there? martin