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#51040: No curved quotes in format-prompt and minibuffer-default-prompt-format Date: Tue, 12 Oct 2021 21:43:28 +0300 Message-ID: <83ily2ozhr.fsf@gnu.org> References: <87o883776l.fsf@gnus.org> <87fstefs2u.fsf@gnus.org> <83lf2yquan.fsf@gnu.org> <83r1cqp5l7.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18050"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 51040@debbugs.gnu.org, larsi@gnus.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 12 20:44:31 2021 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 1maMlL-0004bw-F7 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 12 Oct 2021 20:44:31 +0200 Original-Received: from localhost ([::1]:50512 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1maMlK-0001zF-19 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 12 Oct 2021 14:44:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42914) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1maMks-0001yv-Fl for bug-gnu-emacs@gnu.org; Tue, 12 Oct 2021 14:44:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41851) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1maMks-0000eO-2T for bug-gnu-emacs@gnu.org; Tue, 12 Oct 2021 14:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1maMks-0005b9-0v for bug-gnu-emacs@gnu.org; Tue, 12 Oct 2021 14:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Oct 2021 18:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 51040 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 51040-submit@debbugs.gnu.org id=B51040.163406422421472 (code B ref 51040); Tue, 12 Oct 2021 18:44:01 +0000 Original-Received: (at 51040) by debbugs.gnu.org; 12 Oct 2021 18:43:44 +0000 Original-Received: from localhost ([127.0.0.1]:53393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1maMka-0005aF-4g for submit@debbugs.gnu.org; Tue, 12 Oct 2021 14:43:44 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40958) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1maMkX-0005Zu-Hp for 51040@debbugs.gnu.org; Tue, 12 Oct 2021 14:43:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52094) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1maMkS-0000N9-1I; Tue, 12 Oct 2021 14:43:36 -0400 Original-Received: from [87.69.77.57] (port=1322 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 1maMkR-0000xB-KZ; Tue, 12 Oct 2021 14:43:35 -0400 In-Reply-To: (message from Stefan Kangas on Tue, 12 Oct 2021 10:26:53 -0700) 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" Xref: news.gmane.io gmane.emacs.bugs:217068 Archived-At: > From: Stefan Kangas > Date: Tue, 12 Oct 2021 10:26:53 -0700 > Cc: larsi@gnus.org, 51040@debbugs.gnu.org > > Eli Zaretskii writes: > > > (And why do you use the function and not the variable, btw?) > > This is because that's how it's been designed to be used (not by me): > > - `text-quoting-style' is the user option. > > - Any code that wants to know what nil means should call the function > `text-quoting-style' because the information needed is only available > to C. See default_to_grave_quoting_style in doc.c. Maybe it could be > moved to Lisp but the fundamental issue would be the same. > > The alternative to this is to replicate default_to_grave_quoting_style > everywhere we want to access the `text-quoting-style' variable and > interpret nil. Ouch! what a mess do we have with this stuff! . the doc string of text-quoting-style the function doesn't document its return values, but refers to the variable, so it's easy to conclude that it also returns nil . that doc string says "effective style", without explaining the special processing of nil . the function is not in the ELisp manual, but the variable is, twice(!) > > That's worth a comment, IMO. > > Hmm, I could have sworn this was already documented in the > `text-quoting-style' variable docstring but it seems that it is not. > > I would suggest that we document it there, instead of adding a comment > everywhere we use it. How many places like that do we have that we should worry? > >> IOW, I'm happy to add something, but I'm not sure what that would > >> be. > > > > It should at least say that any callers of the new function will be > > affected by text-quoting-style. > > The `substitute-quotes' docstring currently says this: I was talking about the doc string of text-quoting-style. It refer neither to substitute-command-keys nor to substitute-quotes, only to (some of) their callers. > >> The reason for the change is that we want curved quotes for all the > >> usual reasons > > > > We do? Who is "we" here? I sense another heated argument about this > > issue, which was a hard sell even in the help and error messages. My > > take from that argument is that "we" want to limit these conversions > > to as few contexts as possible, to keep the community at peace, if for > > no other reason. > > ISTR several posts of your own to emacs-devel defending this position? You misunderstood what I was saying there. > > IOW, I'd be okay with an opt-in feature that would perform such > > substitutions, if the Lisp program wants that. But why enforce that? > > I don't see the risk for controversy, as e.g. `format-message' already > does such substitutions. That's part of the substitute-command-keys change with text-quoting-style, and was done in the past. I'm asking why would we want another painful chapter like that. > This change is about avoiding the inconsistency where `format-messages' > does quote substitutions but `format-prompt' does not. What inconsistency? format-messages is about echo-area messages, whereas format-prompt is about something else. That we changed one doesn't mean we must change the other. It's a separate decision, and now we have the benefit of the experience we didn't back then. > If it is too much with `substitute-command-keys', I think it should be > perfectly fine with just doing the quote substitutions. We could use > `format-message' to achieve it in Emacs 28. Sorry, I don't follow you here. > > Not if this becomes now the canon of prompting the user, it isn't. > > In practice, `format-prompt' is only used for prompts where there is a > default. Note that the second (DEFAULT) argument is not optional, which > makes it a bit awkward to use in other cases. > > AFAICT, for messages without a default `format-message' is almost closer > to being the canonical way of formatting a prompt. > > In reality, however, most prompts (in our code at least) don't use any > of them. > > We could of course go in different directions: > > - We say that `(format-prompt "Foo" nil)' is fine and what we want > everywhere. No more `format-message', no more naked strings. > > - We extend the `completing-read' and friends to accept a cons as its > second argument, where the car is the prompt (to be passed to > `format-message') and the cdr is the default. > > - Something else. We are mis-communicating. My main problem is with changing the default behavior of the prompts; I'm okay with having this as an option. How are the other things relevant to that? > (I don't think "salami tactics" is the right term, as that sort of > implies that someone has an overreaching plan. AFAICT, that is > precisely what is missing. ;-) No, it means there's a slip on a slippery slope.