From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Why does `read-multiple-choice' lock user into minbuffer? Date: Thu, 18 Jun 2020 23:47:46 -0500 Message-ID: <87r1ubfyq5.fsf@red-bean.com> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="110037"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: Emacs Development Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 19 06:48:31 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jm8x4-000SWu-Es for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 06:48:30 +0200 Original-Received: from localhost ([::1]:53712 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jm8x3-0003q7-GC for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 00:48:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37652) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jm8wR-0003N5-NC for emacs-devel@gnu.org; Fri, 19 Jun 2020 00:47:51 -0400 Original-Received: from newsp.red-bean.com ([45.79.25.59]:51520) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jm8wP-0002VF-Qy for emacs-devel@gnu.org; Fri, 19 Jun 2020 00:47:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=red-bean.com; s=202005newsp; h=Content-Type:MIME-Version:Message-ID:Date: Reply-To:Subject:To:From:Sender:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=z+ETGQ54rhNvAlxOPl0TS3RmNz4t7aRtNtSg55AB3Uo=; t=1592542068; x=1593751668; b=knO+aO4tIujhzilmCqFNY7srG9S/UgKfr+kbX97UkFttH/FxtZa94SprkLhn0/jObniRxb+E9e p/ydCGFi2JKUWZU8LPIrAJIlplDPMxl1CGG2kiuQmuT/noPfZR91ZuftCUxwih4rgk8xQfXveCH1k BWSh8PcaRtOFhktwc9RA42bI4DQ/Xk0qAl38mPc/fG5De4iAAo6AnhuXweiYlOEHk9NKkUw/Vpnlk DLeG2zFkErNqLr6c49i90frAPqwd7PuTYB3i8Xx4k7tfgGaCkPWkwPQ1u1ZjU2Jbyf46CQ/HpJN1N b/TcwoG/wqyM4splNQrLyicxIQVqKhA7w3ueQ==; Original-Received: from 99-112-125-163.lightspeed.cicril.sbcglobal.net ([99.112.125.163]:59750 helo=floss) by newsp.red-bean.com with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jm8wN-0005N7-3W for emacs-devel@gnu.org; Fri, 19 Jun 2020 04:47:47 +0000 Received-SPF: pass client-ip=45.79.25.59; envelope-from=kfogel@red-bean.com; helo=newsp.red-bean.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/19 00:47:47 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:252333 Archived-At: When I tried to send an email recently, I got prompted by `nsm-query-user' (in lisp/net/nsm.el), as the remote SMTP server I was sending through had rolled over its LetsEncrypt certificate during my Emacs session. This caused me to get prompted with the expected array of choices: (a)lways -> "Accept this certificate this session and for all future sessions" (s)ession only -> "Accept this certificate this session only" (n)o -> "Refuse to use this certificate, and close the connection" etc, etc And while the minibuffer asked me for a response, a new "*Network Security Manager*" buffer was helpfully displayed in a new window. I wanted to copy some text from that buffer, so I tried `C-x o' to get over there. But that didn't work: point was locked into the minibuffer. I tried clicking with my mouse in the other window, but that did not bring me to the window either. And since `nsm-query-user' kills the "*Network Security Manager*" buffer after the user gives her answer, in the end I had no way to copy that text. I couldn't do it while the buffer was being shown to me, and I also couldn't do it after I'd finished responding to `read-multiple-choice' -- because by the time control got back to me, the buffer I wanted no longer existed. Now, a local solution to this problem would be to just not kill the buffer at the end of `nsm-query-user'. (Actually, there are two buffers killed there, and I don't really see why we should kill either of them at the end -- `nsm-query-user' erases them when it needs to.) But I'd like to understand the more general question too: why does `read-multiple-choice' lock the user into the minbuffer so strictly? Its doc string doesn't say anything about this behavior, and other functions that prompt the user (e.g., `find-file') don't enforce minibuffer habitation the same way. Best regards, -Karl