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

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 eggert@cs.ucla.edu-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

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.")
 
 \f
 ;;; 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)))))
 
 \f
-;;; 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.

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

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

[Dani Moncayo]

On Fri, Sep 14, 2012 at 5:56 PM, Stefan Monnier
<monnier@iro.umontreal.ca> 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

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

[Dani Moncayo]

>> > 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

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

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

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

[Jambunathan K]

Dani Moncayo <dmoncayo@gmail.com> 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.
-- 

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.

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

[Juri Linkov]

>> 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 "")

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

[Lars Ingebrigtsen]

Juri Linkov <juri@jurta.org> 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?

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

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Juri Linkov <juri@jurta.org> 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.)

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

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

[Lars Ingebrigtsen]

Stefan Kangas <stefankangas@gmail.com> 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

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

[Drew Adams]

This is what I do in Icicles.
` icicle-handle-default-for-prompt' is called from
`(icicle-)completing-read' and `(icicle-)read-string'.

;; In `(icicle-)completing-read':
(setq prompt
      (icicle-handle-default-for-prompt
       prompt
       ;; If `insert-default-directory' then make DEF
       ;; in prompt relative to `default-directory'.
       (if (and def1  (eq icicle-default-value t)
                insert-default-directory)
           (file-relative-name def1)
         def1)
       (and (eq icicle-default-value t)
            ;; Include in prompt only if
            ;; `insert-default-directory' does not
            ;; insert it as input.
            (or (not insert-default-directory)
                (not (icicle-file-name-input-p))
                (not (equal def1 default-directory))))))
;; In `(icicle-)read-string':
(when default-value
  (setq prompt (icicle-handle-default-for-prompt
                 prompt
                 default-value
                 (eq icicle-default-value t))))

(defun icicle-handle-default-for-prompt (prompt default include)
  "Return PROMPT, possibly changed to format or remove the DEFAULT value.
Argument INCLUDE:
 * nil means do not include DEFAULT in prompt.  Remove it if there.
 * non-nil means include DEFAULT, formatted according to
   `icicle-default-in-prompt-format-function'.

In the existing PROMPT before modification, recognizes inclusion of
a default value according to these possible patterns:

 `minibuffer-default-in-prompt-regexps'
 \"(default ___):\"
 \"(default is ___):\"
 \" [___] \""
  (when (consp default) (setq default  (car default)))
  (dolist                      ; Remove the default, if already there.
      (rgx  (if (boundp 'minibuffer-default-in-prompt-regexps)
                minibuffer-default-in-prompt-regexps
              '(("\\( (default\\(?: is\\)? \\(.*\\))\\):? \\'"  1)
                ("\\( \\[.*\\]\\):? *\\'"                       1))))
    (setq prompt  (replace-regexp-in-string
                   (car rgx) "" prompt nil nil (cadr rgx))))
  (if (and default  include)        ; Add non-nil DEFAULT, if INCLUDE.
      (replace-regexp-in-string
       ".*\\(\\): *\\'"
       (funcall icicle-default-in-prompt-format-function default)
       prompt nil t 1)
    prompt))

(defcustom icicle-default-in-prompt-format-function
           (lambda (default) (format " (%s)" default))
  "Function that formats the default value to include in the prompt.
The function must accept the default value (a string) as its (first)
argument and return a string, which is prepended to the first
occurrence of `: ' in the prompt.  This option has no effect unless
`icicle-default-value' is t."
  :group 'Icicles-Miscellaneous :type 'function)

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

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> 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.

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

[Juri Linkov]

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

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

[Lars Ingebrigtsen]

Juri Linkov <juri@jurta.org> 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

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

[Stefan Monnier]

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

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


        Stefan

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

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> 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

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.

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

[Lars Ingebrigtsen]

Juri Linkov <juri@jurta.org> 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

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

[Lars Ingebrigtsen]

Juri Linkov <juri@jurta.org> 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

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

[Stefan Monnier]

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

No, `nil` should mean there's no default.
`"nil"` is a perfectly valid default value, OTOH.


        Stefan

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

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> 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.
>
> No, `nil` should mean there's no default.
> `"nil"` is a perfectly valid default value, OTOH.

I imagined there was a read-symbol function in use somewhere that used
symbols for completion/defaults, but apparently not -- it's all
completing-read with an intern at the end?

I'll adjust read-prompt to interpret a nil default as "no default".

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

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

[Lars Ingebrigtsen]

OK, the first sweep has now landed on master (I basically grepped for
" (default %" and then did the changes.  Boy, were there many different
ways to "optionally add some defaults" in the code...

 78 files changed, 316 insertions(+), 453 deletions(-)

Look at all the lines saved!  :-)

There's also some of the prompting functions that have some support for
this general idea, but in different ways:

(defun read-regexp (prompt &optional defaults history)
[...]
	 (input (read-from-minibuffer
		 (cond ((string-match-p ":[ \t]*\\'" prompt)
			prompt)
		       ((and default (> (length default) 0))
			 (format "%s (default %s): " prompt
				 (query-replace-descr default)))
		       (t
			(format "%s: " prompt)))
		 nil nil nil (or history 'regexp-history) suggestions t)))

and

(defun read-input-method-name (prompt &optional default inhibit-null)
[...]
  (if default
      (setq prompt (format prompt default)))

Hm.  I had some further notes in here, but...  I put them in a buffer I
didn't save.

*sigh*

I should go have lunch.  I mean dinner.

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> OK, the first sweep has now landed on master (I basically grepped for
> " (default %" and then did the changes. 

The next step here is probably to fix the cases where there's a default,
but where the prompt doesn't mention them.  Like:

(defun last-chance (symbol)
[...]
                             (completing-read
                              "Symbol: " obarray
                              nil nil
                              one nil one)))))

`one' is the default here.  Has anybody written an Emacs-Lisp-aware
grep?  That can list all hits of completing-read where the seventh
parameter isn't nil?  It doesn't sound that difficult to do, but I
thought I'd ask before I start typing...

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> It doesn't sound that difficult to do, but I
> thought I'd ask before I start typing...

Well, whaddaya know, I started typing.  *sigh*

Anyway, this seems to actually work, and I'm amazed at how speedy an all
Emacs solution for this is: Running it over all the Lisp files on trunk
takes 3.2s (on this laptop).

Is this something Emacs should have?  It's not very...  user-friendly;
you have to write the predicate yourself, but it should allow people to
refactor with slightly more ease than with `M-x grep'.

Usage example:

  (lars-find-sexp-in-files "~/src/emacs/trunk/lisp"
			   "[.]el\\'"
			   'completing-read
			    (lambda (form)
			      (and (nth 7 form)
				   (stringp (nth 1 form)))))

(defun lars-find-sexp-in-files (directory match symbol predicate)
  (pop-to-buffer "*matches*")
  (let ((inhibit-read-only t))
    (erase-buffer)
    (dolist (file (directory-files-recursively directory match))
      (message "%s" file)
      (lars-find-sexp-in-file file symbol predicate))
    (grep-mode)))

(defun lars-find-sexp-in-file (file symbol predicate)
  (let ((lines
	 (with-temp-buffer
	   (insert-file-contents file)
	   (lars-find-sexp-in-buffer symbol predicate))))
    (dolist (line lines)
      (insert file ":" line))))

(defun lars-find-sexp-in-buffer (symbol predicate)
  (let ((lines nil))
    (while (re-search-forward (format "(%s[^-a-zA-Z0-9]" symbol) nil t)
      (let ((start (match-beginning 0)))
	(goto-char start)
	(let ((form (ignore-errors (read (current-buffer)))))
	  (when (and (eq (car form) symbol)
		     (funcall predicate form))
	    (goto-char (1+ start))
	    (push (format "%d:%s\n" (count-lines (point-min) start)
			  (buffer-substring-no-properties
			   (line-beginning-position) (line-end-position)))
		  lines)))))
    (nreverse lines)))

      


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

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

[Drew Adams]

> Has anybody written an Emacs-Lisp-aware grep?  That can list all
> hits of completing-read where the seventh parameter isn't nil?
> It doesn't sound that difficult to do, but I thought I'd ask
> before I start typing...

Yes.  See Michael Heerdegen's `el-search.el',
in GNU ELPA:

https://elpa.gnu.org/packages/el-search.html

Not a grep.  Better.

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

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> > Has anybody written an Emacs-Lisp-aware grep?  That can list all
> > hits of completing-read where the seventh parameter isn't nil?
> > It doesn't sound that difficult to do, but I thought I'd ask
> > before I start typing...
>
> Yes.  See Michael Heerdegen's `el-search.el',
> in GNU ELPA:

> https://elpa.gnu.org/packages/el-search.html

Yes, thanks for the mention.  I heard the author is thankful for any
feedback.

Michael.

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

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> Yes.  See Michael Heerdegen's `el-search.el',
>> in GNU ELPA:
>
>> https://elpa.gnu.org/packages/el-search.html
>
> Yes, thanks for the mention.  I heard the author is thankful for any
> feedback.

Looks very impressive.

The emphasis on interactive searches is a bit awkward, though (at least
for me): I don't really want to be typing in pcase forms in the
minibuffer, and I just want to get a occur-like buffer in one step.  Is
that possible?

That would allow the users (i.e., programmers) to just put the stuff in
a function and use at will.  For instance

(el-search-occurs
  "~/src/emacs/trunk/lisp"
  '`(read-string ,(pred stringp) nil ,_ ,t)
  'recursive)

or something.

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Yes, thanks for the mention.  I heard the author is thankful for any
>> feedback.
>
> Looks very impressive.

Oh, and `C-x `' (`next-error') doesn't work when jumping to the next
match in the El Occur buffer.

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

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

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I don't really want to be typing in pcase forms in the minibuffer

The prompt has Elisp mode bindings and a separate history.  M-RET to
start occur.  If you really want everything to be non-interactive

> and I just want to get a occur-like buffer in one step.  Is that
> possible?
>
> That would allow the users (i.e., programmers) to just put the stuff in
> a function and use at will.  For instance
>
> (el-search-occurs
>   "~/src/emacs/trunk/lisp"
>   '`(read-string ,(pred stringp) nil ,_ ,t)
>   'recursive)

I didn't have this use case in mind.  The current way to do this would
write like

#+begin_src emacs-lisp
(el-search--occur
 (el-search-make-search
  '`(read-string ,(pred stringp) nil ,_ ,t)
  (lambda ()
    (el-search-stream-of-directory-files
     (expand-file-name "~/src/emacs/trunk/lisp")))))
#+end_src

I think.  Do you think this is worth an own defun?

Michael.

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

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Oh, and `C-x `' (`next-error') doesn't work when jumping to the next
> match in the El Occur buffer.

Does `C-x `' mean you need to type these two keys repeatedly?  (I made
`n' and `p' jump to the matches.)

Thanks,

Michael.

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

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> I didn't have this use case in mind.  The current way to do this would
> write like
>
> #+begin_src emacs-lisp
> (el-search--occur
>  (el-search-make-search
>   '`(read-string ,(pred stringp) nil ,_ ,t)
>   (lambda ()
>     (el-search-stream-of-directory-files
>      (expand-file-name "~/src/emacs/trunk/lisp")))))
> #+end_src
>
> I think.  Do you think this is worth an own defun?

I think so -- I've been using el-search now for a few hours, and what
takes 90% of my time is typing `C-u M-x el-search-directory RET
~/src/emacs/trunk/lisp/ RET M-p' and then I can edit the pcase form, and
then RET, wait a bit, and O, wait some more, and then I can start
working.

Well, OK, it's really `C-u M-x M-p RET M-p RET M-p', but that's not kind
on the fingers, either.  :-)  I'd just like to plop the some expression in
*scratch* and eval it after each pcase edit.

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

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

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Oh, and `C-x `' (`next-error') doesn't work when jumping to the next
>> match in the El Occur buffer.
>
> Does `C-x `' mean you need to type these two keys repeatedly?  (I made
> `n' and `p' jump to the matches.)

Sorry -- not in the buffer itself, but from the .el buffers.  Like
grep/compile/etc works.

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

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

[Juri Linkov]

> The next step here is probably to fix the cases where there's a default,
> but where the prompt doesn't mention them.  Like:

Are you sure about this change in 1921d2176b?

diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index d8f932e7a4..56c936e773 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -1028,7 +1028,7 @@ tab-bar-rename-tab
           (tab-index (or current-prefix-arg (1+ (tab-bar--current-tab-index tabs))))
           (tab-name (alist-get 'name (nth (1- tab-index) tabs))))
      (list (read-from-minibuffer
-            "New name for tab (leave blank for automatic naming): "
+            (format-prompt "New name for tab" tab-name)
             nil nil nil nil tab-name)
            current-prefix-arg)))
   (let* ((tabs (funcall tab-bar-tabs-function))
@@ -1057,7 +1057,7 @@ tab-bar-rename-tab-by-name
                                               (alist-get 'name tab))
                                             (funcall tab-bar-tabs-function)))))
      (list tab-name (read-from-minibuffer
-                     "New name for tab (leave blank for automatic naming): "
+                     (format-prompt "New name for tab" tab-name)
                      nil nil nil nil tab-name))))
   (tab-bar-rename-tab new-name (1+ (tab-bar--tab-index-by-name tab-name))))
 

I'm not the author of this code, so I don't know how it should work,
but the old prompt with text "leave blank for automatic naming"
makes sense to me.

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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Are you sure about this change in 1921d2176b?

No, I found it kinda puzzling.

>            (tab-name (alist-get 'name (nth (1- tab-index) tabs))))
>       (list (read-from-minibuffer
> -            "New name for tab (leave blank for automatic naming): "
> +            (format-prompt "New name for tab" tab-name)
>              nil nil nil nil tab-name)

The "automatic naming" defaults to tab-name, which is

  (alist-get 'name (nth (1- tab-index) tabs))

In my tests that was never nil, so the "leave blank" didn't seem
possible (and seemed misleading).  But I may well have missed something?

That is, there is no real way to get "automatic naming" interactively?

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

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

[Lars Ingebrigtsen]

(And perhaps I should have skipped that transform because it was puzzling
and less than "obviously right".)

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

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

[Juri Linkov]

>> Are you sure about this change in 1921d2176b?
>
> No, I found it kinda puzzling.
>
>>            (tab-name (alist-get 'name (nth (1- tab-index) tabs))))
>>       (list (read-from-minibuffer
>> -            "New name for tab (leave blank for automatic naming): "
>> +            (format-prompt "New name for tab" tab-name)
>>              nil nil nil nil tab-name)
>
> The "automatic naming" defaults to tab-name, which is
>
>   (alist-get 'name (nth (1- tab-index) tabs))
>
> In my tests that was never nil, so the "leave blank" didn't seem
> possible (and seemed misleading).  But I may well have missed something?
>
> That is, there is no real way to get "automatic naming" interactively?

Here is what I see when trying the old prompt:

  (read-from-minibuffer
    "New name for tab (leave blank for automatic naming): "
    nil nil nil nil "tab-name")

Typing RET returns the empty string "".

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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Here is what I see when trying the old prompt:
>
>   (read-from-minibuffer
>     "New name for tab (leave blank for automatic naming): "
>     nil nil nil nil "tab-name")
>
> Typing RET returns the empty string "".

D'oh.  I missed this bit:

Sixth arg DEFAULT-VALUE, if non-nil, should be a string, which is used
  as the default to ‘read’ if READ is non-nil and the user enters
  empty input.  But if READ is nil, this function does _not_ return
  DEFAULT-VALUE for empty input!  Instead, it returns the empty string.

I'll go over that commit and revert the bits with a nil READ.

But what a...  strange interface.  

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

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

[Juri Linkov]

> Sixth arg DEFAULT-VALUE, if non-nil, should be a string, which is used
>   as the default to ‘read’ if READ is non-nil and the user enters
>   empty input.  But if READ is nil, this function does _not_ return
>   DEFAULT-VALUE for empty input!  Instead, it returns the empty string.
>
> But what a...  strange interface.

It seems this "default" value is needed here only for convenience
of retrieving it into the minibuffer for editing using the M-n key.

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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> Sixth arg DEFAULT-VALUE, if non-nil, should be a string, which is used
>>   as the default to ‘read’ if READ is non-nil and the user enters
>>   empty input.  But if READ is nil, this function does _not_ return
>>   DEFAULT-VALUE for empty input!  Instead, it returns the empty string.
>>
>> But what a...  strange interface.
>
> It seems this "default" value is needed here only for convenience
> of retrieving it into the minibuffer for editing using the M-n key.

Ah, right.

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

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

[Andrii Kolomoiets]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Juri Linkov <juri@linkov.net> writes:
>
>> It seems this "default" value is needed here only for convenience
>> of retrieving it into the minibuffer for editing using the M-n key.
>
> Ah, right.

Is it possible that changes related to this bug leads to broken
minibuffer-electric-default-mode?

Code to evaluate:

    (custom-set-variables
     '(minibuffer-eldef-shorten-default t))
    (minibuffer-electric-default-mode)
    (read-string "prompt (default foo): ")

In Emacs 27 prompt looks like "prompt [foo]: ". After input "z" prompt
will looks like "prompt: z".

In Emacs 28 prompt looks like "prompt (default foo): ". And after input
"z" prompt will looks like "promptz".

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

[Lars Ingebrigtsen]

Andrii Kolomoiets <andreyk.mad@gmail.com> writes:

> Is it possible that changes related to this bug leads to broken
> minibuffer-electric-default-mode?
>
> Code to evaluate:
>
>     (custom-set-variables
>      '(minibuffer-eldef-shorten-default t))
>     (minibuffer-electric-default-mode)
>     (read-string "prompt (default foo): ")
>
> In Emacs 27 prompt looks like "prompt [foo]: ". After input "z" prompt
> will looks like "prompt: z".
>
> In Emacs 28 prompt looks like "prompt (default foo): ". And after input
> "z" prompt will looks like "promptz".

Yup -- it was 19bff57f609854f257780f20043e96fb2eddc713 that included the
": " bit in the portion to be replaced.  This should now be fixed on the
trunk.

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

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

[Juri Linkov]

There is another consequence from the commit de4f347901a.

Is there a real need to duplicate the default value in read-file-name
when the default value is already shown as initial input?

For example, now after typing 'C-x 5 d' (dired-other-frame), the prompt
becomes overly long with the duplicate long default value that now
doesn't fit into the frame width:

  Dired in other frame (directory) [/very/long/path/with/lots/of/subdirectories/]: /very/long/path/with/lots/of/subdirectories/

Here the default value is in square brackets [...] because of my
customized prompt " [%s]" for minibuffer-default-prompt-format.
But with the default format " (default %s)" the prompt would be even longer.

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

[Juri Linkov]

> There is another consequence from the commit de4f347901a.

Sorry, I meant “another case from another commit”.

> Is there a real need to duplicate the default value in read-file-name
> when the default value is already shown as initial input?
>
> For example, now after typing 'C-x 5 d' (dired-other-frame), the prompt
> becomes overly long with the duplicate long default value that now
> doesn't fit into the frame width:
>
>   Dired in other frame (directory) [/very/long/path/with/lots/of/subdirectories/]: /very/long/path/with/lots/of/subdirectories/
>
> Here the default value is in square brackets [...] because of my
> customized prompt " [%s]" for minibuffer-default-prompt-format.
> But with the default format " (default %s)" the prompt would be even longer.

Another case is just ‘C-x d’ (dired) - it displays the duplicate
directory name too: in the default value and the same in the initial input:

  Dired (directory) (default /tmp/foo/bar/): /tmp/foo/bar/

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

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Is there a real need to duplicate the default value in read-file-name
> when the default value is already shown as initial input?
>
> For example, now after typing 'C-x 5 d' (dired-other-frame), the prompt
> becomes overly long with the duplicate long default value that now
> doesn't fit into the frame width:
>
>   Dired in other frame (directory)
> [/very/long/path/with/lots/of/subdirectories/]:
> /very/long/path/with/lots/of/subdirectories/
>
> Here the default value is in square brackets [...] because of my
> customized prompt " [%s]" for minibuffer-default-prompt-format.
> But with the default format " (default %s)" the prompt would be even longer.

Yup; I didn't test read-file-name enough before doing these changes, and
I have now reverted them.  read-file-name's DEFAULT is kinda like other
function's INITIAL, if you squint at it a bit.

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

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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Sun, 13 Sep 2020 11:53:10 +0300
> Cc: 12443@debbugs.gnu.org
> 
> Another case is just ‘C-x d’ (dired) - it displays the duplicate
> directory name too: in the default value and the same in the initial input:
> 
>   Dired (directory) (default /tmp/foo/bar/): /tmp/foo/bar/

Yes, I've noticed this as well.  We need to fix this.

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

[Andrii Kolomoiets]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrii Kolomoiets <andreyk.mad@gmail.com> writes:
>
>> Code to evaluate:
>>
>>     (custom-set-variables
>>      '(minibuffer-eldef-shorten-default t))
>>     (minibuffer-electric-default-mode)
>>     (read-string "prompt (default foo): ")
>>
>> In Emacs 27 prompt looks like "prompt [foo]: ". After input "z" prompt
>> will looks like "prompt: z".
>>
>> In Emacs 28 prompt looks like "prompt (default foo): ". And after input
>> "z" prompt will looks like "promptz".
>
> Yup -- it was 19bff57f609854f257780f20043e96fb2eddc713 that included the
> ": " bit in the portion to be replaced.  This should now be fixed on the
> trunk.

Indeed. Thanks!

But the 'minibuffer-eldef-shorten-default' variable is still ignored.  The
"(default ...)" part of the prompt is not shortened to "[...]".

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

[Lars Ingebrigtsen]

Andrii Kolomoiets <andreyk.mad@gmail.com> writes:

> But the 'minibuffer-eldef-shorten-default' variable is still ignored.  The
> "(default ...)" part of the prompt is not shortened to "[...]".

Ah, yes.  That bit wasn't tested enough (or perhaps at all, come to
think of it).  I've now pushed a fix (after testing and comparing with
how this worked in Emacs 27), so I think this should work now.

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrii Kolomoiets <andreyk.mad@gmail.com> writes:
>
>> But the 'minibuffer-eldef-shorten-default' variable is still ignored.  The
>> "(default ...)" part of the prompt is not shortened to "[...]".
>
> Ah, yes.  That bit wasn't tested enough (or perhaps at all, come to
> think of it).  I've now pushed a fix (after testing and comparing with
> how this worked in Emacs 27), so I think this should work now.

I think basically we've gotten as far as we're going to in this bug
report -- the basic mechanism has been introduced, and the majority of
the callers have been converted, so I'm closing this bug report.  I'm
sure there's more details to be fixed here, but handling those in new,
individual bug reports would probably be better.

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

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

[Basil L. Contovounesios]

[-- Attachment #1: Type: text/plain, Size: 915 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> OK, the first sweep has now landed on master (I basically grepped for
> " (default %" and then did the changes.  Boy, were there many different
> ways to "optionally add some defaults" in the code...
>
>  78 files changed, 316 insertions(+), 453 deletions(-)
>
> Look at all the lines saved!  :-)
>
> There's also some of the prompting functions that have some support for
> this general idea, but in different ways:
>
> (defun read-regexp (prompt &optional defaults history)
> [...]
> 	 (input (read-from-minibuffer
> 		 (cond ((string-match-p ":[ \t]*\\'" prompt)
> 			prompt)
> 		       ((and default (> (length default) 0))
> 			 (format "%s (default %s): " prompt
> 				 (query-replace-descr default)))
> 		       (t
> 			(format "%s: " prompt)))
> 		 nil nil nil (or history 'regexp-history) suggestions t)))

Any reason this function wasn't changed in the end?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Use-format-prompt-in-read-regexp.patch --]
[-- Type: text/x-diff, Size: 1285 bytes --]

From 3d3423ef6705cf157e279c95e5eb8a35b8ca78fb Mon Sep 17 00:00:00 2001
From: "Basil L. Contovounesios" <contovob@tcd.ie>
Date: Sun, 17 Jan 2021 18:56:50 +0000
Subject: [PATCH] Use format-prompt in read-regexp.

* lisp/replace.el (read-regexp): Use format-prompt (bug#12443).
---
 lisp/replace.el | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/lisp/replace.el b/lisp/replace.el
index d41dc98a0d..8f8cbfac54 100644
--- a/lisp/replace.el
+++ b/lisp/replace.el
@@ -866,13 +866,10 @@ read-regexp
 	 ;; Do not automatically add default to the history for empty input.
 	 (history-add-new-input nil)
 	 (input (read-from-minibuffer
-		 (cond ((string-match-p ":[ \t]*\\'" prompt)
-			prompt)
-		       ((and default (> (length default) 0))
-			 (format "%s (default %s): " prompt
-				 (query-replace-descr default)))
-		       (t
-			(format "%s: " prompt)))
+                 (if (string-match-p ":[ \t]*\\'" prompt)
+                     prompt
+                   (format-prompt prompt (and (length> default 0)
+                                              (query-replace-descr default))))
 		 nil nil nil (or history 'regexp-history) suggestions t)))
     (if (equal input "")
 	;; Return the default value when the user enters empty input.
-- 
2.29.2


[-- Attachment #3: Type: text/plain, Size: 11 bytes --]


-- 
Basil

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

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Any reason this function wasn't changed in the end?

[...]

> * lisp/replace.el (read-regexp): Use format-prompt (bug#12443).

No, I think I just missed it.

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

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

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> Any reason this function wasn't changed in the end?
>
> [...]
>
>> * lisp/replace.el (read-regexp): Use format-prompt (bug#12443).
>
> No, I think I just missed it.

Thanks, pushed.

Use format-prompt in read-regexp.
bdb9889f78 2021-01-18 17:58:42 +0000
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=bdb9889f784dc6113a74c259a53cf0623e49ab2d

-- 
Basil