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.bugs Subject: bug#61553: 29.0.60; Inconsistent use of dialog boxes by read-multiple-choice Date: Sun, 19 Feb 2023 11:32:26 +0200 Message-ID: <834jrixaol.fsf@gnu.org> References: <87a61dfur1.fsf@gmail.com> <83edqp330z.fsf@gnu.org> <875yc1foej.fsf@gmail.com> <83a61d2wmp.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24158"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61553-done@debbugs.gnu.org To: arstoffel@gmail.com, Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 19 10:33:25 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pTg4S-000641-Ji for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 19 Feb 2023 10:33:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pTg47-0008Ni-PR; Sun, 19 Feb 2023 04:33:03 -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 1pTg46-0008NL-Gs for bug-gnu-emacs@gnu.org; Sun, 19 Feb 2023 04:33:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pTg46-0002Xn-7M for bug-gnu-emacs@gnu.org; Sun, 19 Feb 2023 04:33:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pTg46-0005t6-2x for bug-gnu-emacs@gnu.org; Sun, 19 Feb 2023 04:33:02 -0500 Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Feb 2023 09:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 61553 X-GNU-PR-Package: emacs Mail-Followup-To: 61553@debbugs.gnu.org, eliz@gnu.org, arstoffel@gmail.com Original-Received: via spool by 61553-done@debbugs.gnu.org id=D61553.167679914922580 (code D ref 61553); Sun, 19 Feb 2023 09:33:01 +0000 Original-Received: (at 61553-done) by debbugs.gnu.org; 19 Feb 2023 09:32:29 +0000 Original-Received: from localhost ([127.0.0.1]:45690 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTg3Z-0005s8-7U for submit@debbugs.gnu.org; Sun, 19 Feb 2023 04:32:29 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pTg3X-0005ru-Bx for 61553-done@debbugs.gnu.org; Sun, 19 Feb 2023 04:32:27 -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 1pTg3S-0002Su-2D; Sun, 19 Feb 2023 04:32:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=j6pIpqgQlCTV1VCKEzdu/ayfm87qbMSv8SHtkQI+5XY=; b=pFVP+XW+U0by 3nM5DOu6NVJF4ANlIICg8CBcxJ6OD+19kvkSaV+l4o7VnGlz7LoKE9jVuw8F8oJM+TDNy3py7He1w I+v+xreTR1MMFaYJYiraTWeWDd2MOrmbRTI4DDtIT/hNAlx287XQ9lXcbGnjDnjI4g1bYdQ7mSsCX MlBASpcz6R+beDdInXAmiLR1FNabWS9263gdxvijI+g7usQS4zPXguvODY5xymfjZdkuso0OZBUWE 9b7wRJHuvAzO7YyCGsM6N0fHXdjZ/DWcNNnAyG1db/MeanVMbWAOZIc0PJVgEYNHuCna5J4zQtqWV 7/3JkOrMOR8h7b8ZuLlGlQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pTg3R-0005xr-CT; Sun, 19 Feb 2023 04:32:21 -0500 In-Reply-To: <83a61d2wmp.fsf@gnu.org> (message from Eli Zaretskii on Thu, 16 Feb 2023 22:17:18 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:256041 Archived-At: > Cc: 61553@debbugs.gnu.org > Date: Thu, 16 Feb 2023 22:17:18 +0200 > From: Eli Zaretskii > > > From: Augusto Stoffel > > Cc: 61553@debbugs.gnu.org > > Date: Thu, 16 Feb 2023 19:36:36 +0100 > > > > On Thu, 16 Feb 2023 at 19:59, Eli Zaretskii wrote: > > > > >> (read-multiple-choice "Question" '((?y "yes") (?n "no")) nil nil t) > > >> > > >> Then I get a minibuffer query, but I would expect a dialog box in the > > >> case as well. > > > > > > The long-form call does a completing-read, and we don't support that > > > via GUI dialogs (how could we?). > > > > Of course. The point is what takes precedence: the decision to prefer a > > dialog over keyboard input, or the decision to do a completing-read > > instead of reading a single char? > > I don't think the function itself can make that decision. Only the > caller knows what's right for the context. > > > The purpose of long-form is to protect the user from doing something > > dangerous by accidentally pressing a key. > > That's only one possible cause of using the long form. There could be > others. > > > So instead of adding a special case for kill-buffer, I would rather > > modify the behavior of RMC to just ignore the long-form argument if > > (use-dialog-box-p) returns t. Apart from that, your patch seems fine. > > I disagree that rmc.el should make that decision. It isn't its call > (pun intended). No further comments, so I've now installed the proposed change on the emacs-29 branch, and I'm closing this bug. > From: Robert Pluim > Cc: arstoffel@gmail.com, 61553@debbugs.gnu.org > Date: Fri, 17 Feb 2023 13:42:35 +0100 > > Eli> Oh, you assume that the reader will not understand that > Eli> completing-read cannot possibly use GUI dialogs? I'm okay with saying > Eli> that explicitly, although someone who uses these APIs must already > Eli> realize that. > > I had to read it carefully to realize that the 'instead' referred to > the use of dialogs. I've made this aspect more explicit in the doc string, thanks.