GNU bug report logs - #51040
No curved quotes in format-prompt and minibuffer-default-prompt-format

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51040 in the body.
You can then email your comments to 51040 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: bug-gnu-emacs <at> gnu.org
Subject: No curved quotes in format-prompt and minibuffer-default-prompt-format
Date: Tue, 5 Oct 2021 12:40:40 -0400

It seems like `format-prompt' and `minibuffer-default-prompt-format'
does not support curved quotes.  Should they?

To reproduce, evaluate this forms in emacs -Q:

    (format-prompt "foo `bar'" nil)

    => "foo `bar': "

And:

    (let ((minibuffer-default-prompt-format " (default `%s')"))
      (format-prompt "foo `bar'" t))

    => "foo `bar' (default `t'): "

My expectation is that I get this, where fancy quotes are supported:

    "foo ‘bar’ (default ‘t’): "

Now, this is easy to fix, but we need to decide if it's okay that
`format-prompt' just runs `substitute-command-keys' on these by default.
I believe that fix should be fine, but maybe I'm missing something.

Message #8 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51040 <at> debbugs.gnu.org
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Tue, 05 Oct 2021 18:44:18 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> It seems like `format-prompt' and `minibuffer-default-prompt-format'
> does not support curved quotes.  Should they?

I think so...

> Now, this is easy to fix, but we need to decide if it's okay that
> `format-prompt' just runs `substitute-command-keys' on these by default.
> I believe that fix should be fine, but maybe I'm missing something.

Perhaps refactor out the curved quote stuff from
`substitute-command-keys' into its own function and then use that?
(Note: I haven't actually looked at that function.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51040 <at> debbugs.gnu.org
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Tue, 5 Oct 2021 13:11:33 -0400

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Perhaps refactor out the curved quote stuff from
> `substitute-command-keys' into its own function and then use that?
> (Note: I haven't actually looked at that function.)

I've been thinking about doing that for a while and I keep going back
and forth.

First, it's a bit tricky to factor this stuff out from
`substitute-command-keys'.  I have a rewrite of that function in the
works (that I should probably finish up at some point), but even then it
is not exactly obvious that this would be super easy and obvious to
factor out in a good way.

So if we do this, I think we should just bite the bullet and duplicate
this functionality in a new function.  It should just be a simple
search+replace, so the duplication shouldn't be too bad.

In some cases, we don't have command substitutions, so it would be nicer
to be able to say `use-fancy-quotes' if that's what we want.  On the
other hand, besides the name there is also no immediate drawback to run
`substitute-command-keys'.

It is kind of nice to know that if we ever expand to have input with
command substitution, it will just work.  For example, what if a prompt
wants to say something like

    (format-prompt "You pressed \\[foo-bar], now input ...")

On the other hand, there are some places where we obviously will never
want to run a "full" `substitute-command-keys', for example I think we
have some places where we awkwardly say (substitute-command-keys "'").

Message #16 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51040 <at> debbugs.gnu.org
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Wed, 06 Oct 2021 10:58:01 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> On the other hand, there are some places where we obviously will never
> want to run a "full" `substitute-command-keys', for example I think we
> have some places where we awkwardly say (substitute-command-keys "'").

Yeah, having a separate function for this would be good, because those
bits are pretty confusing.  But as you say, in this `format-prompt'
case, using `substitute-command-keys' is probably the right thing, since
we could be actually using key defs in the prompt.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #19 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51040 <at> debbugs.gnu.org
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Mon, 11 Oct 2021 13:58:58 -0700

[Message part 1 (text/plain, inline)]

tags 51040 + patch
thanks

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Yeah, having a separate function for this would be good, because those
> bits are pretty confusing.  But as you say, in this `format-prompt'
> case, using `substitute-command-keys' is probably the right thing, since
> we could be actually using key defs in the prompt.

OK, so here's what I propose.  The first patch adds a function
`substitute-quotes' and could go to master, the second one changes
`format-prompt' to use `substitute-command-keys' and could go to
emacs-28.

[0001-New-function-substitute-quotes.patch (text/x-diff, attachment)]

[0002-Use-substitute-command-keys-in-format-prompt.patch (text/x-diff, attachment)]

Message #24 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51040 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Tue, 12 Oct 2021 14:03:28 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> OK, so here's what I propose.  The first patch adds a function
> `substitute-quotes' and could go to master, the second one changes
> `format-prompt' to use `substitute-command-keys' and could go to
> emacs-28.

The first one looks OK to me, but I'm unsure about the second one.  I
mean, it's a small change, but it's hard to say whether this will lead
to obscure regressions in some people's work flows.  So I'm leaning
towards not changing this in emacs-28 at this point.

Eli, do you have an opinion?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #27 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51040 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Tue, 12 Oct 2021 05:36:58 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> The first one looks OK to me, but I'm unsure about the second one.  I
> mean, it's a small change, but it's hard to say whether this will lead
> to obscure regressions in some people's work flows.  So I'm leaning
> towards not changing this in emacs-28 at this point.

I'm fine with putting it on master as well, of course.
The issue it fixes it very minor in any case.

> Eli, do you have an opinion?

Message #30 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51040 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Tue, 12 Oct 2021 15:52:48 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Mon, 11 Oct 2021 13:58:58 -0700
> Cc: 51040 <at> debbugs.gnu.org
> 
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 
> > Yeah, having a separate function for this would be good, because those
> > bits are pretty confusing.  But as you say, in this `format-prompt'
> > case, using `substitute-command-keys' is probably the right thing, since
> > we could be actually using key defs in the prompt.
> 
> OK, so here's what I propose.  The first patch adds a function
> `substitute-quotes' and could go to master, the second one changes
> `format-prompt' to use `substitute-command-keys' and could go to
> emacs-28.
> 
> From e455d509a27b2705f006bc2111228a9a8b8df0b4 Mon Sep 17 00:00:00 2001
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Mon, 11 Oct 2021 22:46:31 +0200
> Subject: [PATCH 1/2] New function substitute-quotes
> 
> * lisp/help.el (substitute-quotes): New function.  (Bug#51040)
> * lisp/cedet/srecode/srt-mode.el (srecode-macro-help):
> * lisp/cus-theme.el (describe-theme-1):
> * lisp/emacs-lisp/cl-extra.el (cl--describe-class):
> * lisp/emacs-lisp/eieio-opt.el (eieio-help-constructor):
> * lisp/emacs-lisp/package.el (describe-package-1):
> * lisp/help-fns.el (help-fns--parent-mode, help-fns--var-risky)
> (help-fns--var-file-local, help-fns--var-bufferlocal)
> (describe-face):
> * lisp/help.el (substitute-command-keys):
> * lisp/progmodes/octave.el (octave-help): Use the new function
> instead of 'substitute-command-keys'.
> * test/lisp/help-tests.el (help-tests-substitute-quotes): New test.

Shouldn't substitute-quotes be documented?

> +(defun substitute-quotes (string)
> +  "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 ‘text-quoting-style’."
> +  (cond ((eq (text-quoting-style) 'curve)
> +         (replace-regexp-in-string
> +          "`" "‘"
> +          (replace-regexp-in-string "'" "’" string)))
> +        ((eq (text-quoting-style) 'straight)
> +         (replace-regexp-in-string "`" "'" string))

Aren't we supposed to use string-replace nowadays in these
situations?

Also, this seems to ignore the nil value of text-quoting-style?

And finally, I think the doc string of text-quoting-style should be
amended, since it says that variable's effect is limited to help text
and format-message, but now it seems its effect will spread much
wider.
> Subject: [PATCH 2/2] Use substitute-command-keys in format-prompt
> 
> * lisp/minibuffer.el (format-prompt): Use substitute-command-keys.
> (Bug#51040)

I'm not sure I understand the rationale for this.  This will change
the appearance of formatted prompts, won't it?  So people will now
have to use \\=' to get a literal apostrophe?  is that really what we
want, and if so, why?

Thanks.

Message #33 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 51040 <at> debbugs.gnu.org, stefan <at> marxist.se
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Tue, 12 Oct 2021 17:17:31 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 51040 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Tue, 12 Oct 2021 14:03:28 +0200
> 
> Stefan Kangas <stefan <at> marxist.se> writes:
> 
> > OK, so here's what I propose.  The first patch adds a function
> > `substitute-quotes' and could go to master, the second one changes
> > `format-prompt' to use `substitute-command-keys' and could go to
> > emacs-28.
> 
> The first one looks OK to me, but I'm unsure about the second one.  I
> mean, it's a small change, but it's hard to say whether this will lead
> to obscure regressions in some people's work flows.  So I'm leaning
> towards not changing this in emacs-28 at this point.
> 
> Eli, do you have an opinion?

I agree, let's not install on emacs-28 anything that doesn't have to
be there.

Message #36 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51040 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Tue, 12 Oct 2021 08:59:15 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> Shouldn't substitute-quotes be documented?

Yes, I also didn't yet add NEWS yet.  Fixed in the attached.

> Aren't we supposed to use string-replace nowadays in these
> situations?

Good catch, fixed.

> Also, this seems to ignore the nil value of text-quoting-style?

The reason is that `text-quoting-style' (the function) handles this
already, and will never return nil.  (This is arguably a bit confusing,
but it is what it is.)

> And finally, I think the doc string of text-quoting-style should be
> amended, since it says that variable's effect is limited to help text
> and format-message, but now it seems its effect will spread much
> wider.

Hmm, in what sense will it spread wider?  I think this will still be
limited to help and messages?  IOW, I'm happy to add something, but I'm
not sure what that would be.

>> * lisp/minibuffer.el (format-prompt): Use substitute-command-keys.
>> (Bug#51040)
>
> I'm not sure I understand the rationale for this.  This will change
> the appearance of formatted prompts, won't it?  So people will now
> have to use \\=' to get a literal apostrophe?  is that really what we
> want, and if so, why?

The reason for the change is that we want curved quotes for all the
usual reasons, and it might be useful to allow command substitutions as
well, in case a prompt wants to show a keybinding.

format-prompt is new in Emacs 28.1, so I guess we're deciding its
semantics now.  That may or may not be strong enough reason to push this
change to emacs-28 instead of master.

New patch attached, thanks for reviewing.

[0001-New-function-substitute-quotes.patch (text/x-diff, attachment)]

Message #39 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51040 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Tue, 12 Oct 2021 19:31:48 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Tue, 12 Oct 2021 08:59:15 -0700
> Cc: larsi <at> gnus.org, 51040 <at> debbugs.gnu.org
> 
> > Also, this seems to ignore the nil value of text-quoting-style?
> 
> The reason is that `text-quoting-style' (the function) handles this
> already, and will never return nil.  (This is arguably a bit confusing,
> but it is what it is.)

That's worth a comment, IMO.

(And why do you use the function and not the variable, btw?)

> > And finally, I think the doc string of text-quoting-style should be
> > amended, since it says that variable's effect is limited to help text
> > and format-message, but now it seems its effect will spread much
> > wider.
> 
> Hmm, in what sense will it spread wider?

In the sense that any caller of substitute-quotes will introduce this
into any text that is constructed from the results.

> I think this will still be limited to help and messages?

There's no way for us to limit the domain of its usage, in practice.

> 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.

> >> * lisp/minibuffer.el (format-prompt): Use substitute-command-keys.
> >> (Bug#51040)
> >
> > I'm not sure I understand the rationale for this.  This will change
> > the appearance of formatted prompts, won't it?  So people will now
> > have to use \\=' to get a literal apostrophe?  is that really what we
> > want, and if so, why?
> 
> 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.

> 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?

> format-prompt is new in Emacs 28.1, so I guess we're deciding its
> semantics now.

I'm sorry, but to me this looks like a salami tactics, not a rational
decision-making process.  We decide that it would be nice to have
format-prompt that replaces boilerplate code, so far so good.  Then we
start adding features to it that have nothing to do with boilerplate,
they change the behavior in significant ways.  IOW, the semantics are
the side effect of adding more and more features without any
discussion of the roadmap or the goal which we want to achieve.

> That may or may not be strong enough reason to push this change to
> emacs-28 instead of master.

Not if this becomes now the canon of prompting the user, it isn't.

> +@defun substitute-quotes
> +This function works like @code{substitute-command-keys}, but only
> +replaces quote characters.

The argument is missing, and is not mentioned in the description.
Also, you need "@end defun" to end it.

Thanks.

Message #42 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51040 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Tue, 12 Oct 2021 10:26:53 -0700

Eli Zaretskii <eliz <at> gnu.org> 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 ‘text-quoting-style’.

>> 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.  ;-)

Message #45 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51040 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Tue, 12 Oct 2021 21:43:28 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Tue, 12 Oct 2021 10:26:53 -0700
> Cc: larsi <at> gnus.org, 51040 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> 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.

Message #48 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51040 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Tue, 12 Oct 2021 16:21:52 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> 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(!)

Yeah, it's a mess.  I suggest we address the documentation issues on
emacs-28 with the attached patch.

I compared the duplicate text, and the only thing that was different is
that the word "variable" had been changed into "option".  So I deleted
the one in the wrong section and that incorrectly said "variable".

[0001-Doc-fixes-for-text-quoting-style.patch (text/x-diff, attachment)]

Message #51 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefan <at> marxist.se>
Cc: 51040 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Wed, 13 Oct 2021 02:44:56 +0300

On 12.10.2021 21:43, Eli Zaretskii wrote:
>> 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.

They're displayed in the same area of the screen, and with similar 
purpose (telling something to the user; prompts also ask something back, 
messages do not).

The different between the echo area and the minibuffer is subtle enough 
for most users, so this kind of difference will almost certainly be 
perceived as inconsistency.

I think the main reason this question hasn't come up before is that 
having any quotes in the prompt, `...' or not, is very rare. Offhand, 
I've found only two such instances in Emacs source tree (in faces.el).

Message #54 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51040 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Wed, 13 Oct 2021 15:07:35 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Tue, 12 Oct 2021 16:21:52 -0700
> Cc: larsi <at> gnus.org, 51040 <at> debbugs.gnu.org
> 
> >   . 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(!)
> 
> Yeah, it's a mess.  I suggest we address the documentation issues on
> emacs-28 with the attached patch.

Thanks.

> +@defun text-quoting-style
> +You should not read the value of the variable
> +@code{text-quoting-style} directly.  Instead, use this function with
> +the same name to correctly handle the nil case described above.
> +@end defun

This should explain why we recommend using the function.

>  DEFUN ("text-quoting-style", Ftext_quoting_style,
>         Stext_quoting_style, 0, 0, 0,
>         doc: /* Return the current effective text quoting style.
> -See variable `text-quoting-style'.  */)
> +If the variable `text-quoting-style' is `grave', `straight' or
> +`curve', just return that value.  If it is nil (the default), return
> +`grave' if curved quotes cannot be displayed, otherwise return
> +`quote'.  Any other value is invalid; in that case return `grave'.

This is okay, with the exception of the "invalid" part: if we allow
it, it is not invalid.  Just say something like "Any other value is
treated as `grave'."

Also, perhaps we should say more about "cannot be displayed".  At
least the manual should elaborate about that, but I think the doc
string should also at least hint what it means.

(Btw, this whole feature has a bug, in that we determine the "cannot
be displayed" part only once, at startup, whereas it in general can be
different on each frame.  But that's a separate issue.)

> +You should never read the value of this variable directly from a Lisp
> +program.  Use the function `text-quoting-style' instead, as that will
> +handle the default nil value.  */);

Again, "handle" is too vague.  Either tell what it means, or perhaps
refer to the doc string of the function for these details.

Message #57 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 51040 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Wed, 13 Oct 2021 14:25:41 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Also, perhaps we should say more about "cannot be displayed".  At
> least the manual should elaborate about that, but I think the doc
> string should also at least hint what it means.

I'm not sure how to describe that in a precise way, but perhaps:

"For example, some text terminals cannot display grave quotes."

Is that sufficient, or do we need even more detail?  I'm not sure what
to add besides perhaps that graphical displays/frames (which word do
we prefer?) can display such characters.

Message #60 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51040 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Wed, 13 Oct 2021 16:22:45 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Wed, 13 Oct 2021 14:25:41 +0200
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 51040 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Also, perhaps we should say more about "cannot be displayed".  At
> > least the manual should elaborate about that, but I think the doc
> > string should also at least hint what it means.
> 
> I'm not sure how to describe that in a precise way, but perhaps:
> 
> "For example, some text terminals cannot display grave quotes."

Yes, and I'd also mention font issues on GUI frames (though those
should be very rare).

> Is that sufficient, or do we need even more detail?

It's fine to be brief here, I think, as the above is sufficiently
self-explanatory.

Message #63 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51040 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Sat, 10 Sep 2022 07:30:24 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> Subject: [PATCH] Doc fixes for 'text-quoting-style'

I've now applied this to Emacs 29 (with some amendments to take Eli's
comments into consideration).

Message #66 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51040 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Sat, 10 Sep 2022 07:38:22 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> Subject: [PATCH 1/2] New function substitute-quotes

Pushed to Emacs 29.

Message #71 received at 51040 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 51040 <at> debbugs.gnu.org
Subject: Re: bug#51040: No curved quotes in format-prompt and
 minibuffer-default-prompt-format
Date: Sat, 10 Sep 2022 08:13:32 +0200

Stefan Kangas <stefan <at> marxist.se> writes:

> It seems like `format-prompt' and `minibuffer-default-prompt-format'
> does not support curved quotes.  Should they?

I've now made this change in Emacs 29.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.