bug#65736: 30.0.50; Extending the use of format-prompt

[Stephen Berman]

0. emacs -Q
1. Invoke read-buffer with a prompt containg grave-style quoting and
   with no default buffer argument, e.g.:
   M-: (read-buffer "Enter `buffer': ")
=> This displays the prompt in the minibuffer with grave-style quoting,
   i.e. as it appears in the invocation.
2. Repeat step 1 but add a default buffer argument, e.g.:
   M-: (read-buffer "Enter `buffer': " "*scratch*")
=> This displays the prompt in the minibuffer with curve-style quoting:
   Enter ‘buffer’ (default *scratch*):  

The different appearances of the prompt with and without the presence of
a default argument is due to commit 50512e36c7, which passes the prompt
string to format-prompt when read-buffer has a non-nil default argument
DEF, but not when DEF is nil.  (The purpose of that commit was to
replace occurrences of prompts containing the string "(default %s)" by
invocations of the then recently introduced function format-prompt; the
fact that this function also calls substitute-command-keys was not a
concern for that commit and its effect was presumably for that reason
overlooked.)

I think the simplest fix is to pass PROMPT to format-prompt regardless
of the presence of a default argument of read-buffer, as in the first
attached patch.

But having substitute-command-keys always apply to the prompt string of
read-buffer raises the question whether it should apply more generally
to prompt strings.  In fact, commit 50512e36c7 did change numerous
mostly mode-specific prompts in several Lisp libraries to pass the
prompt to format-prompt, but in almost all cases those prompts are fixed
strings where applying substitute-command-keys makes no difference.  But
with read-buffer the prompt string is provided by the caller, so its
appearance could be affected by substitute-command-keys.

By default, read-buffer calls (in C) completing-read, which by default
calls read-from-minibuffer, and indeed most, if not all, other functions
that prompt for minibuffer input end up calling read-from-minibuffer.
So passing the prompt string to format-prompt in read-from-minibuffer,
as in the second attached patch (which should be applied instead of the
first patch), would achieve a higher degree of consistency and
simplicity in Emacs in the handling of prompts for minibuffer input, at
least by default.  (With functions that accept a user-defined function,
like read-buffer-function with read-buffer, it would be up to the user
to decide whether or not to use format-prompt, if the function does not
invoke read-from-minibuffer.)

If this change (the second patch) is accepted, it will probably require
adjustments in the Emacs code base, e.g. to avoid double invocations of
format-prompt.  This would partly undo the changes made in 50512e36c7.
I'd be willing to make the needed adjustments in Emacs.

Steve Berman

txtwOTjLspVVb.txt
Description: read-buffer patch

txtxJ8ZJDCTAL.txt
Description: read-from-minibuffer patch