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: Sun, 17 Dec 2023 17:27:46 -0600 Message-ID: <87o7eoe7f1.fsf@red-bean.com> References: <87plz4irev.fsf@red-bean.com> <834jggk4t9.fsf@gnu.org> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37451"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 18 00:28:40 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 1rF0Yq-0009YL-FH for ged-emacs-devel@m.gmane-mx.org; Mon, 18 Dec 2023 00:28:40 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rF0Y4-0007cC-Ew; Sun, 17 Dec 2023 18:27:52 -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 1rF0Y3-0007bl-Ea for emacs-devel@gnu.org; Sun, 17 Dec 2023 18:27:51 -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 1rF0Y1-000079-Nx for emacs-devel@gnu.org; Sun, 17 Dec 2023 18:27:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=red-bean.com; s=202005newsp; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Reply-To:References:In-Reply-To:Subject:To:From: Sender:Cc:Content-ID:Content-Description; bh=4xBqt+ZJ8qnJvjMiMTlesXCC5Itf+wdItwCOF/PKU/g=; t=1702855669; x=1704065269; b=IVE/sBqy45s9DifLPWI202renj+CgJEnL8c5PxNBbBUUZS9+7sRN3gSt9NJQ/5hYhSF2ZCOaALd YBbiW0qk3ZE1UM3v/XTETIcOkCD9j1o/wRU4uTXBPywbA5D+0qndLkv/B4XzWTsawb/BTCloTd25l Snfyl0WfhnlwdeCn7EUn1ccOnR1qyJXrUld0Z7VNYTeZdeIzhhR9PNJVGZaKye4yUqIgvKmKN3gCv QxMAZwvai/NmxxaTcy9+XwoqsxmYZN7mi1acAqlPW4GFmAsmGE2vRnjXr+S1zqv3vB86ZXwt7+nUk 8FZfleF6uuofRDMMJYSkuz2XnQk+TYXHtFJQ==; Original-Received: from 99-112-125-163.lightspeed.cicril.sbcglobal.net ([99.112.125.163]:39912 helo=qfloss) 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 1rF0Xz-005vRb-J9 for emacs-devel@gnu.org; Sun, 17 Dec 2023 23:27:47 +0000 In-Reply-To: <834jggk4t9.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 17 Dec 2023 21:27:30 +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:313962 Archived-At: On 17 Dec 2023, Eli Zaretskii wrote: >It must be optional, probably off by default, and if it's on by >default, there must be a way to get back old behavior. >[...] >P.S. And please wait for enough people who know about this more=20 >than I >do to chime in, before you conclude that you've heard enough. On 17 Dec 2023, Andreas Schwab wrote: >How about adding a command to (re-)display the cert info? I think both of these changes would add more complexity than=20 solving the problem is worth. But there's another route that might be a better solution: One can enter a recursive edit from the `read-multiple-choice'=20 prompt. However, the availability of recursive edit is not=20 obvious from the prompt. The `read-multiple-choice' doc string=20 does say something about it (though of course when the user is=20 facing the prompt they aren't reading this doc string): > If the user enters =E2=80=98edit=E2=80=99, the function starts a recurs= ive > edit. When the user exit the recursive edit, the > multiple-choice prompt gains focus again. It turns out that typing C-r at the prompt is how one "enters=20 `edit'". But I had to guess that -- nothing in the=20 `read-multiple-choice' prompt indicates it. (And I don't know=20 what the word "`edit'" means in the context in which it is used in=20 that doc string -- I infer that there's some convention I'm=20 ignorant of, but if so it's not likely to be a convention that=20 most users know about either.) Fortunately, there *is* a "?" option built in to the=20 `read-multiple-choice' prompt. One can see that extra "?" option=20 by evaluating this code, for example: (read-multiple-choice "Take some action?" '((?o "once" "Just this one time") (?s "session" "For the remainder of this Emacs session") (?a "always") (?n "no") (?v "never" "Not now, not ever, and don't ask again"))) So, how about we change lisp/emacs-lisp/rmc.el:`rmc--show-help' to=20 display how to enter a recursive edit? That is, when the user=20 types "?" at the prompt, the resultant "*Multiple Choice Help*"=20 buffer would always show this extra piece of information about how=20 to enter a recursive edit, in addition to all the options=20 specified in the CHOICES list argument to `read-multiple-choice'. That would solve the problem not only for `nsm-query-user', but=20 for all callers of `read-multiple-choice'. Thoughts? Best regards, -Karl