From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Keep network security info buffers after use Date: Tue, 19 Dec 2023 12:57:04 -0600 Message-ID: <87a5q6rpfj.fsf@red-bean.com> References: <87plz4irev.fsf@red-bean.com> <87sf3ywxak.fsf@red-bean.com> <83h6keicdy.fsf@gnu.org> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36592"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 19 19:58:38 2023 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 1rFfIc-0009KM-CY for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Dec 2023 19:58:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rFfHE-0001v8-DE; Tue, 19 Dec 2023 13:57:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rFfHC-0001u9-Dj for emacs-devel@gnu.org; Tue, 19 Dec 2023 13:57:10 -0500 Original-Received: from sanpietro.red-bean.com ([45.79.25.59]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rFfHA-0006wp-WA; Tue, 19 Dec 2023 13:57:10 -0500 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:References:In-Reply-To:Subject:Cc:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description; bh=E/eQ3cCCyUFAOzfswBH3NFCn9f2+y/kWH7+ohEGYTAI=; t=1703012227; x=1704221827; b=J1wgMClhKGO5em59ZoJhBVWDY/+7f7mhHaBFDPWgR1/lZUlPOzmRSLiXUdcP20warzMzdsjxOjx oEM1ksiSow6hAe1IMCTptxzJBkD4EFveTzAXvF+0cU4i1tM1CZid2Gcn13YCNna+fyVCmyCcvYMZ7 QdhgDePwxtvrk3fVEX5HyIZ+v2HStLNwupTGJNBUmF/U71NNLD1iEVXBwDNn7wFaARjIJoA6BaqoP H1UNMu5EBdlNH4ppIEAhIMcG0kUA8Ehh14vmwKFJnldWrZw9ZvJBL9RV/szzQfSRSZBPR91UPrcjv Evc174xq+aAcRvugPcGVxBj4+LyppjExgOzw==; Original-Received: from [2601:240:c400:76::5755] (port=59268 helo=libq) by sanpietro.red-bean.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rFfH8-0019Lg-CL; Tue, 19 Dec 2023 18:57:06 +0000 In-Reply-To: <83h6keicdy.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 19 Dec 2023 14:51:21 +0200") Received-SPF: pass client-ip=45.79.25.59; envelope-from=kfogel@red-bean.com; helo=sanpietro.red-bean.com 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, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:314011 Archived-At: On 19 Dec 2023, Eli Zaretskii wrote: >I think read-multiple-choice is intentionally programmed to >implement >a modal dialog. That's why "C-x o" is disallowed. > >Once again, I think a special command for getting the cert info >is the >best solution to your problem: it is relatively simple, it is >unintrusive, and it doesn't affect functionalities unrelated to >that >particular problem. By contrast, making significant changes in >rmc.el >just to cater to this use case sounds wrong to me. How about an option that allows `C-x o' to escape from the modal dialog of `read-multiple-choice'? This could be either enabled by an argument to `read-multiple-choice' (then `nsm-query-user' could pass that argument; existing callers of `read-multiple-choice' would be unaffected, unless they start passing that argument too), or by a user-customizable variable (`read-multiple-choice-strict-modal' or something, defaulting to `t' but a user could set it to nil if they wanted a less-strict modal dialog). In general, I do not think it's good when modal dialogs to strictly block the user from taking outside action during the dialog. A user who types `C-x o' while in the minibuffer knows what they are doing. And I can't think of any reason why `read-multiple-choice' *should* block this: what harm is being prevented, to justify interfering with the user's desire to do a particular thing? Users are more familiar with a common command like `C-x o' than with entering a recursive edit (and anyway, as you said: "If we ever decide to change the details of the implementation, C-r will most probably stop working. We don't want to advertise 'features' that can disappear without advance warning."). Best regards, -Karl