bug#51040: No curved quotes in format-prompt and minibuffer-default-prompt-format

[Eli Zaretskii]

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