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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 12 Oct 2021 08:59:15 -0700
> Cc: larsi@gnus.org, 51040@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.