From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Keep network security info buffers after use Date: Thu, 21 Dec 2023 08:29:49 +0200 Message-ID: <83a5q4gjaa.fsf@gnu.org> References: <87plz4irev.fsf@red-bean.com> <87sf3ywxak.fsf@red-bean.com> <83h6keicdy.fsf@gnu.org> <87a5q6rpfj.fsf@red-bean.com> <83wmtaggdq.fsf@gnu.org> <87o7emosib.fsf@red-bean.com> <512a0684-f69c-4c7d-802f-274d4769426e@vodafonemail.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17404"; mail-complaints-to="usenet@ciao.gmane.io" Cc: kfogel@red-bean.com, emacs-devel@gnu.org To: Jens Schmidt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 21 07:30:57 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 1rGCa8-0004LB-Hu for ged-emacs-devel@m.gmane-mx.org; Thu, 21 Dec 2023 07:30:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rGCZS-0003GB-ME; Thu, 21 Dec 2023 01:30:15 -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 1rGCZL-0003Fk-5W for emacs-devel@gnu.org; Thu, 21 Dec 2023 01:30:07 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rGCZI-0007Vx-GM; Thu, 21 Dec 2023 01:30:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=CjmdI6sPL+Wr8Q+eu0bkYEtV++btYc9MUgl3L3iFy74=; b=OX5BthXKm9RDrBwkJOlM W+oVQMC8qVcWhzp4QkBpxcY/NqZBdg7jNjQ1FVAKQIWhoBG0lD6tT9y6Zgkpef10CEJDZG76NnZMc M9Wu2pwoYB8AAobXiREiQeRT/Q3ZjgEzSh5Mh8GpGSfUBRP7DYmgkcs4J7bs02j/FyeabzWdUXCQx pklvNq5HcbCiqsbdF85ucUuKFMoe/0p+vUeZoFq/cxOqy9H2TfYAIB86ona81fyyhiQb+o0+c6JGE DS0T1xNbVL0iTj6tT2/bkgMfKwo53IyuebQgrdeQLr0jF/B8DrWqBGgMHtvapYL0dHfR8Ssz/5nTc WtGFVjwIv4IFLQ==; In-Reply-To: <512a0684-f69c-4c7d-802f-274d4769426e@vodafonemail.de> (message from Jens Schmidt on Wed, 20 Dec 2023 22:34:22 +0100) 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:314032 Archived-At: > Date: Wed, 20 Dec 2023 22:34:22 +0100 > Cc: emacs-devel@gnu.org > From: Jens Schmidt > > On 2023-12-19 21:18, Karl Fogel wrote: > > > Thanks for talking through the possibilities.  We disagree about modal > > dialog behavior, but being maintainer means making decisions sometimes, > > and it's helpful that you've made one here. > > Sorry for chiming in here, but this issue intrigued me. So I tried some > other command where read-multiple-choice is used, namely `kill-buffer' > hen you try to kill a modified buffer. And in that case, I could very > well C-x o out of the multiple choice prompt. For example, to save the > buffer currently being killed with C-x C-s behind the back of the prompt. > > So it seems that in principle read-multiple-choice should be able to do > that. Probably it needs to be called this way or that way to allow that, > I don't know. kill-buffer--possibly-save uses a different form of calling read-multiple-choice, which presents a slightly different UI, see the doc string of read-multiple-choice where it describes the LONG-FORM argument. One side effect of this way of invoking read-multiple-choice is that the users must type long responses, i.e. they cannot just press a single key; this would be annoying if nsm used it. Another side effect is that GUI dialogs cannot be used, which I think would be a UX problem with nsm. It's also slightly less clear in the prompt text it shows. Once again, the nsm prompt is AFAIU intentionally programmed to work like it does, for more than one reason. I don't think it's TRT to change the way we call read-multiple-choice in this case, since the nsm prompt could appear several time during fetching a URL, and being able to press a single key is a huge bonus. The best solution to the original problem suggested so far is what Andreas suggested: a special command to show the information. Patches to that effect, as well as other ideas that don't affect how read-multiple-choice works, are welcome.