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

[Stefan Kangas]

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.

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