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: Mon, 18 Dec 2023 18:00:59 -0600 Message-ID: <87frzzkqmc.fsf@red-bean.com> References: <87plz4irev.fsf@red-bean.com> <834jggk4t9.fsf@gnu.org> <87o7eoe7f1.fsf@red-bean.com> <83ttofifaf.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="19671"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 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 01:02:13 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 1rFNYq-0004sZ-NJ for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Dec 2023 01:02:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rFNXn-0002Gi-9l; Mon, 18 Dec 2023 19:01:07 -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 1rFNXl-0002GJ-Ff for emacs-devel@gnu.org; Mon, 18 Dec 2023 19:01:05 -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 1rFNXh-0006u3-M4; Mon, 18 Dec 2023 19:01:05 -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=3LLukK3ob1jlHTMSQV6G1hwPc2eBSt4TwejDJNkwf0U=; t=1702944060; x=1704153660; b=mh4W9A8h6K/mBeiFtw0l0jnj914yTSGdjxnRtLU7Y+olCBeE4uLgwLpyXpFONQw/AAgZP1FpQi7 dAfnk5wvLLXpfXVRyj8YhU/yOwtwRedrqxpzuyk7lJXO5aBxcfQIwFCOEaLIbWARTm9B+SkPJ2ijL bHb5pNaiU9GT0mLvR7xYudQRLBTuGwY+LqCToTkY7AXYtcf/DCeh7Iv3ipmTm3QAtW5sBbsTT41SB 5DN0fq8EsrQ6uls2dbsogqMFo8qhqoAQhx5N0TbyCWsVtzxQzTaJ8ZwGIaeL+3z3z7GQ1LiTgzTar q4i6pQ2VaAOSSkXDRNp8iQPyYO+QoAuwCwMA==; Original-Received: from [12.106.183.66] (port=57281 helo=hummy) 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 1rFNXf-007kOK-Ln; Tue, 19 Dec 2023 00:00:59 +0000 In-Reply-To: <83ttofifaf.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 18 Dec 2023 19:36:24 +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:313987 Archived-At: On 18 Dec 2023, Eli Zaretskii wrote: >> From: Karl Fogel >> Date: Sun, 17 Dec 2023 17:27:46 -0600 >> >> So, how about we change lisp/emacs-lisp/rmc.el:`rmc--show-help' >> to >> display how to enter a recursive edit? > >We don't advertise that key for a reason, so I don't think this >is a >good idea. Okay. I'm curious what that reason is, if you have time to explain, but I'm fine accepting this decision as a given. >I actually don't understand why you rejected the tow ideas >proposed to >you. Personally, I think Andreas's idea is the better one, and >not >too hard to implement. It also has the nice advantage that it >solves >the exact problem you had and nothing else. My problem with Andreas's idea... >How about adding a command to (re-)display the cert info? ...is that I don't see how the user is likely to know about the existence of this new command. It's already kind of rare to get prompted for cert info at all (it only happens to me every once in a while, usually when I'm starting to use on a new machine). Remember, the cert or server info *is* already being displayed to the user when the `read-multiple-choice' prompt happens -- the info is right there in a displayed buffer. The problem is that it's not obvious how to get out of the minibuffer and into that displayed buffer, for example to grab the info into the kill ring, or save it to a file, so that one can go back and use the info after the prompt cycle is done. Now, it turns out that one *can* get out of the minibuffer, by entering a recursive edit with C-r, but nothing in the `read-multiple-choice' prompt indicates this, so the user would have to "just know" about this possibility. If `C-x o' would just work at the `read-multiple-choice' prompt, and enable one to leave the minibuffer to travel around to other windows, that would also be a fine solution. Actually, probably it would be the best solution, now that I think about it. Are there reasons why `read-multiple-choice' disallows this by default? I don't know much about the constraints and requirements of that function; I just know how it's been treating me lately :-). Best regards, -Karl