From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#51040: No curved quotes in format-prompt and minibuffer-default-prompt-format Date: Tue, 12 Oct 2021 10:26:53 -0700 Message-ID: References: <87o883776l.fsf@gnus.org> <87fstefs2u.fsf@gnus.org> <83lf2yquan.fsf@gnu.org> <83r1cqp5l7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="392"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 51040@debbugs.gnu.org, larsi@gnus.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 12 19:28:19 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 1maLZa-000AML-GS for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 12 Oct 2021 19:28:18 +0200 Original-Received: from localhost ([::1]:57514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1maLZY-00062K-PP for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 12 Oct 2021 13:28:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54086) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1maLZK-00061h-Ud for bug-gnu-emacs@gnu.org; Tue, 12 Oct 2021 13:28:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40711) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1maLZK-0003MM-MF for bug-gnu-emacs@gnu.org; Tue, 12 Oct 2021 13:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1maLZK-0000On-Im for bug-gnu-emacs@gnu.org; Tue, 12 Oct 2021 13:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Oct 2021 17:28:02 +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.16340596271364 (code B ref 51040); Tue, 12 Oct 2021 17:28:02 +0000 Original-Received: (at 51040) by debbugs.gnu.org; 12 Oct 2021 17:27:07 +0000 Original-Received: from localhost ([127.0.0.1]:52227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1maLYN-0000Lr-Tc for submit@debbugs.gnu.org; Tue, 12 Oct 2021 13:27:07 -0400 Original-Received: from mail-pj1-f41.google.com ([209.85.216.41]:45848) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1maLYK-0000LD-Mt for 51040@debbugs.gnu.org; Tue, 12 Oct 2021 13:27:01 -0400 Original-Received: by mail-pj1-f41.google.com with SMTP id ls14-20020a17090b350e00b001a00e2251c8so162224pjb.4 for <51040@debbugs.gnu.org>; Tue, 12 Oct 2021 10:27:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=2US4gJ80hxHPzMv8gvlyCdG0uTzMvK2DmTaKhpfixqA=; b=w+UWu04ENelVO2dYkZsMWcKfeZp9foHwZ2eSgzj3q2BqUTX6iJDmlyAO7SLUTNW+BA HHD/oK9fgQyZNGUzJxLH2TFZYZKpbOtU125SQ0mcopGeuWPnEJXOZ+IxVXR0iu3zbTo3 P56BaQl7yOb4p1JJRMv9WxYrOitqPvE409gzM+wo8Q0axnBYyrhWH5e2ErdBsUD52Ac+ wLXTQriwKoa78CyM8I3DloFWpWkWhDqm9lm/jiPY1d5n8b2q1os1lnjYB0Y+7moOb/ja fe2lajKlomh/xzQyGcYx4X2FRrQyHDtPcLs3c0/htH8/t5Y0id24Ktv7Y3pIv2iGIJ4W TtpQ== X-Gm-Message-State: AOAM530IJc7UoZw5I1VM4wSga/GWJoIZf1sW2C0Cmr2qMXWIwuRPIKpO 1sYDmsGJs4SKLg7slgcDEHBErh7CoLzoYypNsX0= X-Google-Smtp-Source: ABdhPJyvecappJapwVZWRP5oplnDv2fGcno6NintN6Y8Wl77if8wpY6np4MOSAbPBlMm0hTOagwW4zkJVD4YuaF/OLw= X-Received: by 2002:a17:90a:460a:: with SMTP id w10mr7536486pjg.132.1634059614082; Tue, 12 Oct 2021 10:26:54 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 12 Oct 2021 10:26:53 -0700 In-Reply-To: <83r1cqp5l7.fsf@gnu.org> 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:217063 Archived-At: 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. > 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. >> 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: Substitute quote characters for display. Each grave accent ` is replaced by left quote, and each apostrophe ' is replaced by right quote. Left and right quote characters are specified by =E2=80=98text-quoting-style=E2=80=99. >> 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? But see below. >> and it might be useful to allow command substitutions as well, in >> case a prompt wants to show a keybinding. > > But the change forces this on anyone who uses format-prompt, doesn't > it? And we are now advertising format-prompt as THE canonical way of > producing prompts, don't we? And we are proactively converting code > that issues prompts to use format-prompt, don't we? So soon enough > every prompt will be forced to undergo these substitutions, whether it > wants or not. Even worse, commands that don't use format-prompt will > produce prompts that look differently from those which do. Right? > > 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. Granted, it does not do the full monty (command substitutions) but it does do the replacement of quoting characters. See its docstring. So the argument is already won for the "quoted curves in messages where it is supported" side, AFAICT. This change is about avoiding the inconsistency where `format-messages' does quote substitutions but `format-prompt' does not. 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. > 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. IOW, this area is not exactly clear-cut yet, but there's a slow movement towards more unification along certain lines. I agree that so far no one has presented an overall roadmap, so the process is clearly a bit haphazard. (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. ;-)