bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Dani Moncayo
Severity: minor

Hello,

I see that some commands that use the minibuffer such as "C-x b"
(switch-to-buffer) present the default value in the minibuffer prompt,
as "(default <value>)", while other commands such as "C-x r m"
(bookmark-set) omit the "default " part, i.e, they show the default
value just as "(value)".

I see no reason for this inconsistency, neither I see the need for the
"default " part.

So, hereby I propose to fix this, i.e., to omit the "default " in
those commands where this is currently shown.

TIA.


In GNU Emacs 24.2.50.1 (i386-mingw-nt6.1.7601)
 of 2012-09-13 on DANI-PC
Bzr revision: 110018 [hidden email]-20120913162306-gi60swatqiu16m6e
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -I../../libs/libxpm-3.5.8/include -I../../libs/libxpm-3.5.8/src
 -I../../libs/libpng-1.4.10 -I../../libs/zlib-1.2.6
 -I../../libs/giflib-4.1.4-1/include -I../../libs/jpeg-6b-4/include
 -I../../libs/tiff-3.8.2-1/include
 -I../../libs/libxml2-2.7.8-w32-bin/include/libxml2
 -I../../libs/gnutls-3.0.16/include
 -I../../libs/libiconv-1.14-2-mingw32-dev/include'

Important settings:
  value of $LANG: ESN
  locale-coding-system: cp1252
  default enable-multibyte-characters: t


--
Dani Moncayo



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Stefan Monnier
> I see no reason for this inconsistency,

Agreed.  The officially sanctioned behavior is to use "(default ...)".

> neither I see the need for the "default " part.

That would make the job of minibuffer-electric-default-mode harder
(more false positives).

> So, hereby I propose to fix this, i.e., to omit the "default " in
> those commands where this is currently shown.

I find the "(default ...)" text to use up too much space for my own taste, so
I use the patch below to rewrite it on-the-fly to "[...]".


        Stefan


Using submit branch file:///home/monnier/src/emacs/bzr/trunk/
=== modified file 'lisp/minibuf-eldef.el'
--- lisp/minibuf-eldef.el 2012-04-09 13:05:48 +0000
+++ lisp/minibuf-eldef.el 2012-09-14 15:54:47 +0000
@@ -34,15 +34,17 @@
 ;;; Code:
 
 (defvar minibuffer-default-in-prompt-regexps
-  '(("\\( (default\\>.*)\\):? \\'" . 1) ("\\( \\[.*\\]\\):? *\\'" . 1))
+  '(("\\( (default\\(?: is\\)? \\(.*\\))\\):? \\'" 1 " [\\2]")
+    ("\\( \\[.*\\]\\):? *\\'" 1))
   "A list of regexps matching the parts of minibuffer prompts showing defaults.
 When `minibuffer-electric-default-mode' is active, these regexps are
 used to identify the portions of prompts to elide.
 
-Each entry is either a string, which should be a regexp matching the
-default portion of the prompt, or a cons cell, who's car is a regexp
-matching the default part of the prompt, and who's cdr indicates the
-regexp subexpression that matched.")
+Each entry is of the form (REGEXP MATCH-NUM &optional REWRITE),
+where REGEXP should match the default part of the prompt,
+MATCH-NUM is the subgroup that matched the actual default indicator,
+and REWRITE, if present, is a string to pass to `replace-match' that
+should be displayed in its place.")
 
 
 ;;; Internal variables
@@ -85,15 +87,25 @@
  ;; See the prompt contains a default input indicator
  (while regexps
   (setq match (pop regexps))
-  (if (re-search-forward (if (stringp match) match (car match)) nil t)
-      (setq regexps nil)
+  (if (re-search-forward (car match) nil t)
+              (if (consp (cddr match))
+                  (let ((inhibit-read-only t)
+                        (buffer-undo-list t)
+                        (props (text-properties-at (match-beginning (cadr match)))))
+                    (replace-match (caddr match) nil nil nil (cadr match))
+                    (set-text-properties (match-beginning (cadr match))
+                                         (match-end (cadr match))
+                                         props)
+                    (setq match nil)
+                    (goto-char (point-min)))
+                (setq regexps nil))
     (setq match nil)))))
     (if (not match)
  ;; Nope, so just make sure our post-command-hook isn't left around.
  (remove-hook 'post-command-hook #'minibuf-eldef-update-minibuffer t)
       ;; Yup; set things up so we can frob the prompt as the state of
       ;; the input string changes.
-      (setq match (if (consp match) (cdr match) 0))
+      (setq match (cadr match))
       (setq minibuf-eldef-overlay
     (make-overlay (match-beginning match) (match-end match)))
       (setq minibuf-eldef-showing-default-in-prompt t)
@@ -124,10 +136,6 @@
    (overlay-put minibuf-eldef-overlay 'intangible t)))))
 
 
-;;; Note this definition must be at the end of the file, because
-;;; `define-minor-mode' actually calls the mode-function if the
-;;; associated variable is non-nil, which requires that all needed
-;;; functions be already defined.  [This is arguably a bug in d-m-m]
 ;;;###autoload
 (define-minor-mode minibuffer-electric-default-mode
   "Toggle Minibuffer Electric Default mode.




Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Drew Adams
> > I see no reason for this inconsistency,
>
> Agreed.  The officially sanctioned behavior is to use "(default ...)".

> > neither I see the need for the "default " part.
>
> That would make the job of minibuffer-electric-default-mode harder
> (more false positives).

No offense to Miles or anyone else, but that mode is just a workaround for the
bother introduced by Emacs adding `(default ...)' here and there (but not yet
everywhere).  Just get rid of the cause, instead of sticking a band-aid on the
wound.

> > So, hereby I propose to fix this, i.e., to omit the "default " in
> > those commands where this is currently shown.
>
> I find the "(default ...)" text to use up too much space for
> my own taste, so I use the patch below to rewrite it on-the-fly
> to "[...]".

Just get rid of "(default ...)" altogether.  A user can use `M-n' to see the
default value, and `M-n RET' instead of `RET' to choose it.  No big deal, and a
lot less noise.

---

Or do as I do in Icicles: give users the choice, across all minibuffer prompts.
They have an option, with these possible values:

nil               - Do not insert default value
                    or add it to prompt.
t                 - Add default value to prompt
                    (except for `read-file-name' and
                    `read-from-minibuffer').
                    Do not insert it.
`insert-start'    - Insert default value
                    and leave cursor at start.
`insert-end'      - Insert default value
                    and leave cursor at end.
`preselect-start' - Insert and preselect default value;
                    leave cursor at beginning.
`preselect-end'   - Insert and preselect default value;
                    leave cursor at end.

The default value of the option is `t' (mainly to be closer to what people are
used to in vanilla Emacs).  But what I am suggesting for Emacs is the `nil'
behavior as default: do nothing with the default value.  (Personally, I use
`insert-end'.)




Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Dani Moncayo
In reply to this post by Stefan Monnier
On Fri, Sep 14, 2012 at 5:56 PM, Stefan Monnier
<[hidden email]> wrote:
>> I see no reason for this inconsistency,
>
> Agreed.  The officially sanctioned behavior is to use "(default ...)".

Then all commands should be consistent on that.

>> neither I see the need for the "default " part.
>
> That would make the job of minibuffer-electric-default-mode harder
> (more false positives).

I didn't know about that minor mode.  I've just read its docstring and
I think it isn't worth it, because:
* It makes the input string jump right and left, making harder to
concentrate on it.
* Users obviously know that the default value is used only when no
value is provided, so there is no need to be inserting/removing the
default value from the prompt.
* The only advantage I can see is to save space in the minibuffer when
you are entering some text, but usually the frame is wide enough not
to care about this.

(Anyway, I don't understand why the way of formatting the default
value in the prompt string should make the job of this mode harder,
because if we know what the default value is and how is formatted in
the prompt string, it should be trivial to identify that part at the
right side of the prompt string.  Maybe I'm missing something...)

>> So, hereby I propose to fix this, i.e., to omit the "default " in
>> those commands where this is currently shown.
>
> I find the "(default ...)" text to use up too much space for my own taste, so
> I use the patch below to rewrite it on-the-fly to "[...]".

Thanks, but if we agree that there is a problem here (or there is room
for improvement), it would be better to fix this in the vanilla Emacs.

--
Dani Moncayo



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Dani Moncayo
In reply to this post by Drew Adams
>> > So, hereby I propose to fix this, i.e., to omit the "default " in
>> > those commands where this is currently shown.
>>
>> I find the "(default ...)" text to use up too much space for
>> my own taste, so I use the patch below to rewrite it on-the-fly
>> to "[...]".
>
> Just get rid of "(default ...)" altogether.  A user can use `M-n' to see the
> default value, and `M-n RET' instead of `RET' to choose it.  No big deal, and a
> lot less noise.

But some users may prefer to see the default value in the prompt.

> ---
>
> Or do as I do in Icicles: give users the choice, across all minibuffer prompts.
> They have an option, with these possible values:
>
> nil               - Do not insert default value
>                     or add it to prompt.
> t                 - Add default value to prompt
>                     (except for `read-file-name' and
>                     `read-from-minibuffer').
>                     Do not insert it.
> `insert-start'    - Insert default value
>                     and leave cursor at start.
> `insert-end'      - Insert default value
>                     and leave cursor at end.
> `preselect-start' - Insert and preselect default value;
>                     leave cursor at beginning.
> `preselect-end'   - Insert and preselect default value;
>                     leave cursor at end.
>

That looks like a good improvement, indeed.

> The default value of the option is `t' (mainly to be closer to what people are
> used to in vanilla Emacs).  But what I am suggesting for Emacs is the `nil'
> behavior as default: do nothing with the default value.  (Personally, I use
> `insert-end'.)

I'm not sure what would be the more suitable default value (whether
nil ot t), in any case, this is secondary, as anyone could customize
it.

--
Dani Moncayo



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Stefan Monnier
In reply to this post by Dani Moncayo
>>> I see no reason for this inconsistency,
>> Agreed.  The officially sanctioned behavior is to use "(default ...)".
> Then all commands should be consistent on that.

Agreed.

> (Anyway, I don't understand why the way of formatting the default
> value in the prompt string should make the job of this mode harder,
> because if we know what the default value is and how is formatted in
> the prompt string, it should be trivial to identify that part at the
> right side of the prompt string.  Maybe I'm missing something...)

The problem is that we don't always know how it is formatted in the
prompt (it might be a shortened version, for example).

> Thanks, but if we agree that there is a problem here (or there is room
> for improvement), it would be better to fix this in the vanilla Emacs.

It's a matter of taste (some people prefer the "(default ...)").


        Stefan



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Dani Moncayo
>> Thanks, but if we agree that there is a problem here (or there is room
>> for improvement), it would be better to fix this in the vanilla Emacs.
>
> It's a matter of taste (some people prefer the "(default ...)").

maybe, but other people (Drew, you, me and I guess many others) prefer
other behavior.

Therefore, it seems that this should be user-configurable.

--
Dani Moncayo



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Jambunathan K-3
Dani Moncayo <[hidden email]> writes:

>>> Thanks, but if we agree that there is a problem here (or there is room
>>> for improvement), it would be better to fix this in the vanilla Emacs.
>>
>> It's a matter of taste (some people prefer the "(default ...)").
>
> maybe, but other people (Drew, you, me and I guess many others) prefer
> other behavior.
>
> Therefore, it seems that this should be user-configurable.

A new/first-time user will need a hint.

An experienced user or a user with some experience - one who knows what
to expect, where and when - will find it a clutter.

I believe I belong to the third camp.
--



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Drew Adams
> >> It's a matter of taste (some people prefer the "(default ...)").
> >
> > maybe, but other people (Drew, you, me and I guess many
> > others) prefer other behavior.
> >
> > Therefore, it seems that this should be user-configurable.
>
> A new/first-time user will need a hint.
>
> An experienced user or a user with some experience - one who
> knows what to expect, where and when - will find it a clutter.

So make the default value do what we do now, if you really think such a hint is
important for newbies.  But give users the choice.

FWIW, I do not think that newbies need such a hint, anymore than they might need
hints about hitting TAB for completion or a host of other things one could
imagine are as new to them as `M-n'.  But I am not adamantly against providing
such hints by default.




Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Juri Linkov
In reply to this post by Dani Moncayo
>> It's a matter of taste (some people prefer the "(default ...)").
>
> maybe, but other people (Drew, you, me and I guess many others) prefer
> other behavior.
>
> Therefore, it seems that this should be user-configurable.

(defcustom minibuffer-default-prompt-format " (default %s)"
 "Default format."
 :type 'string)

Example of usage:

(let ((default "def"))
  (read-from-minibuffer
   (format "Set bookmark%s: "
           (format minibuffer-default-prompt-format default))))

Other possible values:

(setq minibuffer-default-prompt-format " [%s]")
(setq minibuffer-default-prompt-format "")



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Stefan Kangas-2
Lars Ingebrigtsen <[hidden email]> writes:

> Juri Linkov <[hidden email]> writes:
>
>> (defcustom minibuffer-default-prompt-format " (default %s)"
>>  "Default format."
>>  :type 'string)
>>
>> Example of usage:
>>
>> (let ((default "def"))
>>   (read-from-minibuffer
>>    (format "Set bookmark%s: "
>>            (format minibuffer-default-prompt-format default))))
>>
>> Other possible values:
>>
>> (setq minibuffer-default-prompt-format " [%s]")
>> (setq minibuffer-default-prompt-format "")
>
> I think that makes a lot of sense.  Does anybody have an opinion here?

I think this sounds like a good idea; consistency is good.

How about taking it even further?   Something along the lines of:

    (format-prompt PROMPT &optional DEFAULT)

    (format-prompt "Set bookmark" default)
    => "Set bookmark [foobar]: "

    (format-prompt "Goto char")
    => "Goto char: "

(This would avoid having to always remember to use double formats like
above.)



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Stefan Monnier
>>> (defcustom minibuffer-default-prompt-format " (default %s)"
>>>  "Default format."
>>>  :type 'string)
>>>
>>> Example of usage:
>>>
>>> (let ((default "def"))
>>>   (read-from-minibuffer
>>>    (format "Set bookmark%s: "
>>>            (format minibuffer-default-prompt-format default))))

Nitpick: `read-from-minibuffer` is a low-level function which you should
never use directly but only within other `read-<foo>` functions.
E.g. here one should probably use `read-string` instead.

Please make sure that `minibuffer-electric-default-mode` pays attention
to it.

> How about taking it even further?   Something along the lines of:
>
>     (format-prompt PROMPT &optional DEFAULT)
>
>     (format-prompt "Set bookmark" default)
>     => "Set bookmark [foobar]: "
>
>     (format-prompt "Goto char")
>     => "Goto char: "

LGTM,


        Stefan




Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Lars Ingebrigtsen
In reply to this post by Stefan Kangas-2
Stefan Kangas <[hidden email]> writes:

> How about taking it even further?   Something along the lines of:
>
>     (format-prompt PROMPT &optional DEFAULT)
>
>     (format-prompt "Set bookmark" default)
>     => "Set bookmark [foobar]: "
>
>     (format-prompt "Goto char")
>     => "Goto char: "
>
> (This would avoid having to always remember to use double formats like
> above.)

I like it.  I just grepped for '(default %' just to see how this would
look in practice.  Most of them look good:

diff --git a/lisp/dired-x.el b/lisp/dired-x.el
index 873d586ca1..5335855d6e 100644
--- a/lisp/dired-x.el
+++ b/lisp/dired-x.el
@@ -339,8 +339,7 @@ dired--mark-suffix-interactive-spec
             ('(16)
              (let* ((dflt (char-to-string dired-marker-char))
                     (input (read-string
-                            (format
-                             "Marker character to use (default %s): " dflt)
+                            (format-prompt "Marker character to use" dflt)
                             nil nil dflt)))
                (aref input 0)))
             (_ dired-marker-char))))
diff --git a/lisp/frame.el b/lisp/frame.el
index 081d3010e9..d9e49d50ba 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -760,7 +760,7 @@ close-display-connection
    (list
     (let* ((default (frame-parameter nil 'display))
            (display (completing-read
-                     (format "Close display (default %s): " default)
+                     (format-prompt "Close display" default)
                      (delete-dups
                       (mapcar (lambda (frame)
                                 (frame-parameter frame 'display))

However, there's things like:

         (setq from-coding (read-coding-system
                            (format "Recode filename %s from (default %s): "
                                    filename default-coding)
                            default-coding))

These are surprisingly rare, but, uhm...  perhaps format-prompt could
take a format string?  The function would then look like:

(defun format-prompt (prompt default &rest format-args)
  )

where it would call `format' on PROMPT and FORMAT-ARGS.

So that would then be:

         (setq from-coding (read-coding-system
                            (format-prompt "Recode filename %s"
                                            default-coding filename)
                            default-coding))


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



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Stefan Kangas-2
Lars Ingebrigtsen <[hidden email]> writes:

> I like it.  I just grepped for '(default %' just to see how this would
> look in practice.  Most of them look good:

Agreed.

> (defun format-prompt (prompt default &rest format-args)
>   )

Sounds good to me.



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Juri Linkov
In reply to this post by Lars Ingebrigtsen
> However, there's things like:
>
> (setq from-coding (read-coding-system
>    (format "Recode filename %s from (default %s): "
>    filename default-coding)
>    default-coding))
>
> These are surprisingly rare, but, uhm...  perhaps format-prompt could
> take a format string?  The function would then look like:
>
> (defun format-prompt (prompt default &rest format-args)
>   )
>
> where it would call `format' on PROMPT and FORMAT-ARGS.
>
> So that would then be:
>
> (setq from-coding (read-coding-system
>    (format-prompt "Recode filename %s"
>                                             default-coding filename)
>    default-coding))

Simpler would be to format arguments separately:

         (setq from-coding (read-coding-system
                            (format-prompt (format "Recode filename %s from"
                                                   filename)
                                           default-coding)
                            default-coding))

that would allow easier replacement of 'format' with 'gettext' later:

         (setq from-coding (read-coding-system
                            (format-prompt (gettext "Recode filename %s from"
                                                     filename)
                                           default-coding)
                            default-coding))



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Lars Ingebrigtsen
Juri Linkov <[hidden email]> writes:

>> (setq from-coding (read-coding-system
>>    (format-prompt "Recode filename %s"
>>                                             default-coding filename)
>>    default-coding))
>
> Simpler would be to format arguments separately:
>
> (setq from-coding (read-coding-system
>    (format-prompt (format "Recode filename %s from"
>                                                    filename)
>           default-coding)
>    default-coding))

Yeah, but that's longer and more awkward, isn't it?

> that would allow easier replacement of 'format' with 'gettext' later:
>
> (setq from-coding (read-coding-system
>    (format-prompt (gettext "Recode filename %s from"
>                                                      filename)
>           default-coding)
>    default-coding))

I don't think we have to have gettexting in mind, because that's never
gonna happen.  :-)

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



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Lars Ingebrigtsen
In reply to this post by Juri Linkov
Stefan Monnier <[hidden email]> writes:

> Couldn't `format-prompt` do the `gettext` internally?

Yup -- all the prompts fed to format-prompt are meant for display, so
that should be fine.

Anyway, I went ahead and pushed this to Emacs 28, but I've only
converted two (2) of the (at least) couple hundreds of callers, because
I wanted to see if there were any further comments on the concept (or
the interface) before digging into the rest of the call sites.

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



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Juri Linkov
> Anyway, I went ahead and pushed this to Emacs 28,

Maybe the final separator (colon) should be customizable as well.
What if someone wants to use the same character as used in shell, i.e. '$'.
Then moving the currently hard-coded colon to the default value
" (default %s): " will allow the users to customize it to
" (default %s)$ "

> but I've only converted two (2) of the (at least) couple hundreds of
> callers, because I wanted to see if there were any further comments on
> the concept (or the interface) before digging into the rest of the
> call sites.

Shouldn't one of these calls (namely 'describe-function') be further
simplified with

diff --git a/lisp/help-fns.el b/lisp/help-fns.el
index d302c05283..617f6ae5e8 100644
--- a/lisp/help-fns.el
+++ b/lisp/help-fns.el
@@ -151,9 +151,7 @@ describe-function
    (let* ((fn (function-called-at-point))
           (enable-recursive-minibuffers t)
           (val (completing-read
-                (if fn
-                    (format-prompt "Describe function" fn)
-                  "Describe function: ")
+                (format-prompt "Describe function" fn)
                 #'help--symbol-completion-table
                 (lambda (f) (or (fboundp f) (get f 'function-documentation)))
                 t nil nil

But something is still wrong - with the nil default value the prompt becomes:

  "Describe function (default nil): "

whereas it should be

  "Describe function: "

It seems 'format-prompt' should not use 'minibuffer-default-prompt-format'
when 'default' is nil.



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Lars Ingebrigtsen
Juri Linkov <[hidden email]> writes:

> Maybe the final separator (colon) should be customizable as well.
> What if someone wants to use the same character as used in shell, i.e. '$'.
> Then moving the currently hard-coded colon to the default value
> " (default %s): " will allow the users to customize it to
> " (default %s)$ "

Good idea.  I'll adjust the variable and the code.

> Shouldn't one of these calls (namely 'describe-function') be further
> simplified with
>
> diff --git a/lisp/help-fns.el b/lisp/help-fns.el
> index d302c05283..617f6ae5e8 100644
> --- a/lisp/help-fns.el
> +++ b/lisp/help-fns.el
> @@ -151,9 +151,7 @@ describe-function
>     (let* ((fn (function-called-at-point))
>            (enable-recursive-minibuffers t)
>            (val (completing-read
> -                (if fn
> -                    (format-prompt "Describe function" fn)
> -                  "Describe function: ")
> +                (format-prompt "Describe function" fn)
>                  #'help--symbol-completion-table
>                  (lambda (f) (or (fboundp f) (get f 'function-documentation)))
>                  t nil nil
>
> But something is still wrong - with the nil default value the prompt becomes:
>
>   "Describe function (default nil): "
>
> whereas it should be
>
>   "Describe function: "

Yes, that's why you can't use format-prompt when there's no default value.

> It seems 'format-prompt' should not use 'minibuffer-default-prompt-format'
> when 'default' is nil.

nil is a perfectly valid default value in many prompts.

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



Reply | Threaded
Open this post in threaded view
|

bug#12443: 24.2.50; Default values in the minibuffer prompt (fix inconsisntecy)

Lars Ingebrigtsen
In reply to this post by Juri Linkov
Juri Linkov <[hidden email]> writes:

> Maybe the final separator (colon) should be customizable as well.
> What if someone wants to use the same character as used in shell, i.e. '$'.
> Then moving the currently hard-coded colon to the default value
> " (default %s): " will allow the users to customize it to
> " (default %s)$ "

Actually, I changed my mind -- the format-prompt function is about
formatting the default value.  There'll still be many, many prompts out
there that aren't sent through the function, so it'd be inconsistent to
allow changing the ": " on some prompts but not others.

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



123