bug#7567: Please add a history variable to read-regexp

bug#7567: Please add a history variable to read-regexp

[Lennart Borgman]

Also take care of the strange query-replace-from-history-variable in
read-regexp.

bug#7567: Please add a history variable to read-regexp

[Lennart Borgman]

On Mon, Dec 6, 2010 at 3:24 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> Also take care of the strange query-replace-from-history-variable in
> read-regexp.

No answer. Was something unclear here?

The current read-regexp use is problematic for example in
multi-isearch-read-matching-buffers and
multi-occur-in-matching-buffers. I think a common history variable
could be used for those cases, but they currently use the default
regexp-history variable which seems totally inappropriate.

bug#7567: Please add a history variable to read-regexp

[Drew Adams]

> > Also take care of the strange query-replace-from-history-variable in
> > read-regexp.
> 
> No answer. Was something unclear here?
> 
> The current read-regexp use is problematic for example in
> multi-isearch-read-matching-buffers and
> multi-occur-in-matching-buffers. I think a common history variable
> could be used for those cases, but they currently use the default
> regexp-history variable which seems totally inappropriate.

I don't mean to meddle here, but it's not clear to me why `regexp-history' is
not appropriate in the contexts you mention.  The user is inputting a regexp.
Why shouldn't previous regexps the user inputted be available in the input
history for this operation?

bug#7567: Please add a history variable to read-regexp

[Lennart Borgman]

On Mon, Dec 6, 2010 at 11:57 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> > Also take care of the strange query-replace-from-history-variable in
>> > read-regexp.
>>
>> No answer. Was something unclear here?
>>
>> The current read-regexp use is problematic for example in
>> multi-isearch-read-matching-buffers and
>> multi-occur-in-matching-buffers. I think a common history variable
>> could be used for those cases, but they currently use the default
>> regexp-history variable which seems totally inappropriate.
>
> I don't mean to meddle here, but it's not clear to me why `regexp-history' is
> not appropriate in the contexts you mention.  The user is inputting a regexp.
> Why shouldn't previous regexps the user inputted be available in the input
> history for this operation?


Thanks for asking, I thought it was clear.

Why should that regexp be used to make buffer names? It is probably a
regexp that has been used for matching strings in buffers. (It might
of course be a regexp from a search in *Buffer List*, but that is not
the normal case.)

bug#7567: Please add a history variable to read-regexp

[Juri Linkov]

> No answer. Was something unclear here?

Why so impatient, you waited for the answer only half a day :)

> The current read-regexp use is problematic for example in
> multi-isearch-read-matching-buffers and
> multi-occur-in-matching-buffers. I think a common history variable
> could be used for those cases, but they currently use the default
> regexp-history variable which seems totally inappropriate.

`regexp-history' is a common history variable for all commands
that read a regexp from the minibuffer.  I don't understand
what is wrong with that?

bug#7567: Please add a history variable to read-regexp

[Drew Adams]

> Thanks for asking, I thought it was clear.

You're welcome.

> Why should that regexp be used to make buffer names? It is probably a
> regexp that has been used for matching strings in buffers.

Why is it "probably" that?

I use regexps interactively all over the place.  Matching text in a buffer is
only one use.

> (It might of course be a regexp from a search in *Buffer List*,
> but that is not the normal case.)

IMO, there is no "normal" case.

This is a general limitation wrt history vars.  But it cannot really be
otherwise.  You might want some particular values to be available on a given
history list in some context, and you (or I) might want them to not be available
on that list in another context.

We can add more history vars to get finer-grained control, but then you miss out
if you want to access something that it was decided should be on another history
list.

It's impossible to have it both ways, because the user's intention is a variable
that cannot easily and always be taken into consideration.  IOW, there are some
things the programmer can decide when writing the function call that reads input
(you can use any history var you want, including new ones), but still you cannot
always know what the user really needs/wants.

bug#7567: Please add a history variable to read-regexp

[Lennart Borgman]

On Tue, Dec 7, 2010 at 12:11 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> Thanks for asking, I thought it was clear.
>
> You're welcome.
>
>> Why should that regexp be used to make buffer names? It is probably a
>> regexp that has been used for matching strings in buffers.
>
> Why is it "probably" that?
>
> I use regexps interactively all over the place.  Matching text in a buffer is
> only one use.

Can you give examples of other interactive uses, please? That might
make it easier to know what we are really talking about.

bug#7567: Please add a history variable to read-regexp

[Lennart Borgman]

On Tue, Dec 7, 2010 at 12:03 AM, Juri Linkov <juri@jurta.org> wrote:
>
>> The current read-regexp use is problematic for example in
>> multi-isearch-read-matching-buffers and
>> multi-occur-in-matching-buffers. I think a common history variable
>> could be used for those cases, but they currently use the default
>> regexp-history variable which seems totally inappropriate.
>
> `regexp-history' is a common history variable for all commands
> that read a regexp from the minibuffer.  I don't understand
> what is wrong with that?

Please take a look in the current code in query-replace-read-from.
This currently does not use read-regexp (which it should) because it
is easier to switch history variable if you don't.

bug#7567: Please add a history variable to read-regexp

[Drew Adams]

> >> Why should that regexp be used to make buffer names? It is 
> >> probably a regexp that has been used for matching strings in buffers.
> >
> > Why is it "probably" that?
> >
> > I use regexps interactively all over the place.  Matching 
> > text in a buffer is only one use.
> 
> Can you give examples of other interactive uses, please? That might
> make it easier to know what we are really talking about.

Use your imagination. But yes, of course anything _could_ be put in a buffer, so
conceivably any use of a regexp could involve matching some buffer's text...

What about the very functions you mentioned?  Why wouldn't regexps they read
also be useful in some buffer?  Or vice versa, why couldn't some buffer-text
regexp be useful for those functions?

Anyway, if you insist, here are a few examples: `icicle-customize-apropos':
Customize all user options matching REGEXP.  Likewise, customize faces and
groups.  Likewise Icicles apropos functions.  I even use it in the Icicles
version of `apropos-zippy' (but the vanilla version uses (interactive "s...")).
`icicle-find-tag': Navigate among all tags whose names match REGEXP.   I use it
for `icicle-keyword-list', which reads a list of keywords, each of which could
actually be a regexp.  I use it in `icicle-widen-candidates', which adds
completion candidates based on an alternative regexp.

And there are specialized vanilla regexp histories, such as
`dired-regexp-history'.

And you yourself mentioned matching a buffer name.  (I do that in
`icicle-add-buffer-config', for instance: buffer names to match for inclusion
and for exclusion as completion candidates.)

Now you can imagine lots of others, I think.  A regexp can be used anywhere, and
a function to read a regexp can be used in any regexp use case.

I guess what I'd really like to ask you is this: Please give a reason why
`read-regexp', which is extremely general, should _not_ use the general regexp
history variable.

bug#7567: Please add a history variable to read-regexp

[Stefan Monnier]

So after reading the rest of the thread, I think I finally understand
that you want to "add a history *argument* to read-regexp", right?
Then it sounds perfectly acceptable.

Using correct words always helps.  Of course, explaining the problem in
more details is also another way to avoid falling into such
misunderstaning, via redundancy.


        Stefan

bug#7567: Please add a history variable to read-regexp

[Drew Adams]

In answer to a question from Lennart off list I realize that I misunderstood his
request.  In spite of the Subject line, which I think I skipped over, I
mistakenly thought he was just requesting that `read-regexp' use a _different_
history variable (e.g. `read-regexp-history') in its call to
`read-from-minibuffer'.

I didn't realize that he was really requesting that `read-regexp' accept an
additional, optional HISTORY arg, which would be passed to
`read-from-minibuffer' (nil HISTORY would mean to pass `regexp-history', as
now).

Now that I understand, I agree with Lennart.  There is no reason not to let
`read-regexp' be even more general by parameterizing it with a HISTORY
parameter.

Sorry for misunderstanding.  In case others also misunderstood, this is the
idea:

(defun read-regexp (prompt &optional default-value history)
  "...
Non-nil HISTORY is a symbol to use as the history variable.
If HISTORY is nil, `regexp-history' is used."
...)

bug#7567: Please add a history variable to read-regexp

[Juri Linkov]

> Please take a look in the current code in query-replace-read-from.
> This currently does not use read-regexp (which it should) because it
> is easier to switch history variable if you don't.

`query-replace' should share its history with `from' and `to' parts by default
as it does now.  But I agree that it could provide the same defaults
as `read-regexp'.

bug#7567: Please add a history variable to read-regexp

[Juri Linkov]

> It's impossible to have it both ways, because the user's intention is a variable
> that cannot easily and always be taken into consideration.  IOW, there are some
> things the programmer can decide when writing the function call that reads input
> (you can use any history var you want, including new ones), but still you cannot
> always know what the user really needs/wants.

Does Icicles provide a way for the user to select and switch
history variables dynamically while the minibuffer is active?
This looks like a possible way to overcome this limitation.

bug#7567: Please add a history variable to read-regexp

[Juri Linkov]

> So after reading the rest of the thread, I think I finally understand
> that you want to "add a history *argument* to read-regexp", right?
> Then it sounds perfectly acceptable.

For consistency, `read-regexp' could have the same function signature
as other minibuffer reading functions, e.g. like `read-string':

  (read-string PROMPT &optional INITIAL-INPUT HISTORY DEFAULT-VALUE INHERIT-INPUT-METHOD)

  (read-regexp PROMPT &optional INITIAL-INPUT HISTORY DEFAULT-VALUE INHERIT-INPUT-METHOD)

bug#7567: Please add a history variable to read-regexp

[Lennart Borgman]

On Wed, Dec 8, 2010 at 2:57 AM, Juri Linkov <juri@jurta.org> wrote:
>> So after reading the rest of the thread, I think I finally understand
>> that you want to "add a history *argument* to read-regexp", right?
>> Then it sounds perfectly acceptable.
>
> For consistency, `read-regexp' could have the same function signature
> as other minibuffer reading functions, e.g. like `read-string':
>
>  (read-string PROMPT &optional INITIAL-INPUT HISTORY DEFAULT-VALUE INHERIT-INPUT-METHOD)
>
>  (read-regexp PROMPT &optional INITIAL-INPUT HISTORY DEFAULT-VALUE INHERIT-INPUT-METHOD)

I agree.

In addition to that when we have that in place then a number of places
in the code should be updated to use it instead of read-string. (And
some new history vars for it should be added.)

bug#7567: Please add a history variable to read-regexp

[Drew Adams]

> > It's impossible to have it both ways, because the user's 
> > intention is a variable that cannot easily and always be
> > taken into consideration.  IOW, there are some
> > things the programmer can decide when writing the function 
> > call that reads input (you can use any history var you want,
> > including new ones), but still you cannot
> > always know what the user really needs/wants.
> 
> Does Icicles provide a way for the user to select and switch
> history variables dynamically while the minibuffer is active?
> This looks like a possible way to overcome this limitation.

No, it doesn't. ;-)

bug#7567: Please add a history variable to read-regexp

[Drew Adams]

> For consistency, `read-regexp' could have the same function signature
> as other minibuffer reading functions, e.g. like `read-string':
> 
>   (read-string PROMPT &optional INITIAL-INPUT HISTORY 
> DEFAULT-VALUE INHERIT-INPUT-METHOD)
> 
>   (read-regexp PROMPT &optional INITIAL-INPUT HISTORY 
> DEFAULT-VALUE INHERIT-INPUT-METHOD)

I agree with that.  But I also think that it might be good to use
`completing-read', to allow (lax) completion against the history.  IOW, use the
history for both completion and the usual history access.

FWIW, I use completion for regexp reading, but more often against a different
set of candidates from the history.

E.g., for `icicle-customize-apropos', I use this to read a regexp that matches
an option name:

(completing-read "Customize (regexp): " obarray
                 nil nil nil 'regexp-history)

And for `icicle-find-tag' I use this to read a regexp that matches a tag:

(completing-read
  "Find tag matching regexp: "
;;; $$$ Or should we just read a regexp against `regexp-history'?
  (if (fboundp 'tags-lazy-completion-table)
      (tags-lazy-completion-table) ; Emacs 23+
    'tags-complete-tag) ; Emacs < 23
  nil nil nil 'find-tag-history
  (funcall (or find-tag-default-function
               (get major-mode 'find-tag-default-function)
               'find-tag-default)))

You can tell from the code comment here that I'm not sure the tag COLLECTION
here is better than a regexp history as COLLECTION.

(But in Icicles you can hit a key in the minibuffer to complete against the
current history, so it's usually better to offer a different set for
COLLECTION.)

Anyway, I think that Juri's proposal (built on Lennart's) would be an
improvement.

bug#7567: Please add a history variable to read-regexp

[Lennart Borgman]

On Tue, Dec 7, 2010 at 4:48 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> So after reading the rest of the thread, I think I finally understand
> that you want to "add a history *argument* to read-regexp", right?
> Then it sounds perfectly acceptable.
>
> Using correct words always helps.  Of course, explaining the problem in
> more details is also another way to avoid falling into such
> misunderstaning, via redundancy.

(Seems like this excuse was not sent.)

Thanks.

Sorry Drew, Stefan and Juri for the misunderstandings and trouble.

bug#7567: Please add a history variable to read-regexp

[Juri Linkov]

> In addition to that when we have that in place then a number of places
> in the code should be updated to use it instead of read-string. (And
> some new history vars for it should be added.)

Please show these places.  I think most of them should share
the same regexp history.

bug#7567: Please add a history variable to read-regexp

[Stefan Monnier]

>> So after reading the rest of the thread, I think I finally understand
>> that you want to "add a history *argument* to read-regexp", right?
>> Then it sounds perfectly acceptable.

> For consistency, `read-regexp' could have the same function signature
> as other minibuffer reading functions, e.g. like `read-string':

>   (read-string PROMPT &optional INITIAL-INPUT HISTORY DEFAULT-VALUE INHERIT-INPUT-METHOD)

>   (read-regexp PROMPT &optional INITIAL-INPUT HISTORY DEFAULT-VALUE INHERIT-INPUT-METHOD)

No: new such functions should not offer both INITIAL-INPUT and
DEFAULT-VALUE.  Instead, they should (like read-regexp) only accept
DEFAULT-VALUE (and automatically add it to the prompt in the standard
format).


        Stefan

bug#7567: Please add a history variable to read-regexp

[Stefan Monnier]

> I agree with that.  But I also think that it might be good to use
> `completing-read', to allow (lax) completion against the history.
> IOW, use the history for both completion and the usual history access.

I think this is a bad idea: completing-read is for completion against
"possible answers" which should be kept separate from
history-completion.  We could/should let TAB perform history completion
for non-completing-reads, but if we do that, it should be under the
control of the user.

Personally, I think that M-p should perform history completion, and
that's what my .emacs does.


        Stefan

bug#7567: Please add a history variable to read-regexp

[Drew Adams]

> > I agree with that.  But I also think that it might be good to use
> > `completing-read', to allow (lax) completion against the history.
> > IOW, use the history for both completion and the usual 
> > history access.
> 
> I think this is a bad idea: completing-read is for completion against
> "possible answers" which should be kept separate from
> history-completion.  

I generally agree.  In this case, there was no (is no) other completion, so
there are no other-kind of completion candidates to keep the history separate
from.  But yes, I agree.

> We could/should let TAB perform history 
> completion for non-completing-reads, but if we do that, it should
> be under the control of the user.

Agreed, especially the last part.

I really meant only that it's good in general to have more use of (lax)
completion and less use of things like `read-string' and `read-regexp' that
provide what lax completion provides but without any completion.

> Personally, I think that M-p should perform history completion, and
> that's what my .emacs does.

That would be OK.  The big advantage of completion vs `M-p' etc. is that you can
get more directly to a history entry, no matter how long ago you originally
entered it.

Another possibility - not at all the same thing, but useful in such a case as
well as in others - is what Icicles does: Use another key (`M-o') to let you
complete against the history and insert the result into the minibuffer (without
committing it).  This uses a recursive minibuffer and is available during any
minibuffer input - not just during completing reads.

bug#7567: Please add a history variable to read-regexp

[Drew Adams]

> No: new such functions should not offer both INITIAL-INPUT and
> DEFAULT-VALUE.  Instead, they should (like read-regexp) only accept
> DEFAULT-VALUE (and automatically add it to the prompt in the standard
> format).

Let INITIAL-INPUT be. -- John Lennon

No one is forced to use it.  What did it ever do to you? ;-)

bug#7567: Please add a history variable to read-regexp

[Stefan Monnier]

>> No: new such functions should not offer both INITIAL-INPUT and
>> DEFAULT-VALUE.  Instead, they should (like read-regexp) only accept
>> DEFAULT-VALUE (and automatically add it to the prompt in the standard
>> format).

> Let INITIAL-INPUT be. -- John Lennon

> No one is forced to use it.  What did it ever do to you? ;-)

It's too low-level: better provide a DEFAULT-VALUE and then the function
can decide to do as we do (i.e. put default in prompt and in M-n) or as
they do (put it as the initial contents, selected so that
delete-selection-mode can get rid of it in a pinch).


        Stefan

bug#7567: Please add a history variable to read-regexp

[Stefan Monnier]

> I really meant only that it's good in general to have more use of (lax)
> completion and less use of things like `read-string' and `read-regexp' that
> provide what lax completion provides but without any completion.

That's OK: just don't do it by changing the callers of read-regexp but
by changing read-regexp's behavior.


        Stefan

bug#7567: Please add a history variable to read-regexp

[Drew Adams]

> >> No: new such functions should not offer both INITIAL-INPUT and
> >> DEFAULT-VALUE.  Instead, they should (like read-regexp) only accept
> >> DEFAULT-VALUE (and automatically add it to the prompt in 
> >> the standard format).
> 
> > Let INITIAL-INPUT be. -- John Lennon
> 
> > No one is forced to use it.  What did it ever do to you? ;-)
> 
> It's too low-level: better provide a DEFAULT-VALUE and then 
> the function

What function?

> can decide to do as we do (i.e. put default in prompt and in 
> M-n) or as they do

They who/what?

> (put it as the initial contents, selected so that
> delete-selection-mode can get rid of it in a pinch).

Who/what does that, and how?

bug#7567: Please add a history variable to read-regexp

[Stefan Monnier]

>> It's too low-level: better provide a DEFAULT-VALUE and then 
>> the function

> What function?

read-<foo> (i.e. read-regexp in the case at hand).

>> can decide to do as we do (i.e. put default in prompt and in 
>> M-n) or as they do
> They who/what?

Most other GUI applications.


        Stefan

bug#7567: Please add a history argument to read-regexp

[Juri Linkov]

This patch fixes bug#7567 by adding a history argument to `read-regexp':

=== modified file 'lisp/replace.el'
--- lisp/replace.el	2012-09-09 22:15:24 +0000
+++ lisp/replace.el	2012-09-20 08:28:05 +0000
@@ -574,12 +575,14 @@ (defvar regexp-history nil
 (defvar occur-collect-regexp-history '("\\1")
   "History of regexp for occur's collect operation")
 
-(defun read-regexp (prompt &optional default-value)
+(defun read-regexp (prompt &optional default-value history)
   "Read regexp as a string using the regexp history and some useful defaults.
 Prompt for a regular expression with PROMPT (without a colon and
 space) in the minibuffer.  The optional argument DEFAULT-VALUE
 provides the value to display in the minibuffer prompt that is
 returned if the user just types RET.
+Non-nil HISTORY is a symbol to use as the history list.
+If HISTORY is nil, `regexp-history' is used.
 Values available via M-n are the string at point, the last isearch
 regexp, the last isearch string, and the last replacement regexp."
   (let* ((defaults
@@ -603,11 +606,11 @@ (defun read-regexp (prompt &optional def
 		 (format "%s (default %s): " prompt
 			 (query-replace-descr default-value))
 	       (format "%s: " prompt)))
-	   nil nil nil 'regexp-history defaults t)))
+	   nil nil nil (or history 'regexp-history) defaults t)))
     (if (equal input "")
 	(or default-value input)
       (prog1 input
-	(add-to-history 'regexp-history input)))))
+	(add-to-history (or history 'regexp-history) input)))))
 

 
This allows more functions to use `read-regexp' with other history lists
as was discussed here in bug#7567 a year ago.

=== modified file 'lisp/replace.el'
--- lisp/replace.el	2012-09-09 22:15:24 +0000
+++ lisp/replace.el	2012-09-20 08:28:05 +0000
@@ -128,20 +128,21 @@ (defun query-replace-read-from (prompt r
   (if query-replace-interactive
       (car (if regexp-flag regexp-search-ring search-ring))
     (let* ((history-add-new-input nil)
+	   (prompt
+	    (if query-replace-defaults
+		(format "%s (default %s -> %s): " prompt
+			(query-replace-descr (car query-replace-defaults))
+			(query-replace-descr (cdr query-replace-defaults)))
+	      (format "%s: " prompt)))
 	   (from
 	    ;; The save-excursion here is in case the user marks and copies
 	    ;; a region in order to specify the minibuffer input.
 	    ;; That should not clobber the region for the query-replace itself.
 	    (save-excursion
-	      (read-from-minibuffer
-	       (if query-replace-defaults
-		   (format "%s (default %s -> %s): " prompt
-			   (query-replace-descr (car query-replace-defaults))
-			   (query-replace-descr (cdr query-replace-defaults)))
-		 (format "%s: " prompt))
-	       nil nil nil
-	       query-replace-from-history-variable
-	       nil t))))
+	      (if regexp-flag
+		  (read-regexp prompt nil query-replace-from-history-variable)
+		(read-from-minibuffer
+		 prompt nil nil nil query-replace-from-history-variable nil t)))))
       (if (and (zerop (length from)) query-replace-defaults)
 	  (cons (car query-replace-defaults)
 		(query-replace-compile-replacement
@@ -1130,9 +1135,9 @@ (defun occur-read-primary-args ()
 		  "\\&"
 		;; Get the regexp for collection pattern.
 		(let ((default (car occur-collect-regexp-history)))
-		  (read-string
+		  (read-regexp
 		   (format "Regexp to collect (default %s): " default)
-		   nil 'occur-collect-regexp-history default)))
+		   default 'occur-collect-regexp-history)))
 	    ;; Otherwise normal occur takes numerical prefix argument.
 	    (when current-prefix-arg
 	      (prefix-numeric-value current-prefix-arg))))))
@@ -1219,14 +1224,11 @@ (defun multi-occur-in-matching-buffers (
    (cons
     (let* ((default (car regexp-history))
 	   (input
-	    (read-from-minibuffer
+	    (read-regexp
 	     (if current-prefix-arg
 		 "List lines in buffers whose names match regexp: "
 	       "List lines in buffers whose filenames match regexp: ")
-	     nil
-	     nil
-	     nil
-	     'regexp-history)))
+	     nil 'regexp-history)))
       (if (equal input "")
 	  default
 	input))

=== modified file 'lisp/isearch.el'
--- lisp/isearch.el	2012-09-09 22:15:24 +0000
+++ lisp/isearch.el	2012-09-20 08:23:25 +0000
@@ -1649,9 +1681,9 @@ (defun isearch-occur (regexp &optional n
 		 (isearch-done nil t)
 		 (isearch-clean-overlays)
 		 (let ((default (car occur-collect-regexp-history)))
-		   (read-string
+		   (read-regexp
 		    (format "Regexp to collect (default %s): " default)
-		    nil 'occur-collect-regexp-history default)))
+		    default 'occur-collect-regexp-history)))
 	     ;; Otherwise normal occur takes numerical prefix argument.
 	     (when current-prefix-arg
 	       (prefix-numeric-value current-prefix-arg))))))

=== modified file 'lisp/progmodes/grep.el'
--- lisp/progmodes/grep.el	2012-04-20 08:48:50 +0000
+++ lisp/progmodes/grep.el	2012-09-20 08:24:55 +0000
@@ -817,11 +831,11 @@ (defun grep-expand-template (template &o
 (defun grep-read-regexp ()
   "Read regexp arg for interactive grep."
   (let ((default (grep-tag-default)))
-    (read-string
+    (read-regexp
      (concat "Search for"
 	     (if (and default (> (length default) 0))
 		 (format " (default \"%s\"): " default) ": "))
-     nil 'grep-regexp-history default)))
+     default 'grep-regexp-history)))
 
 (defun grep-read-files (regexp)
   "Read files arg for interactive grep."

=== modified file 'lisp/dired.el'
--- lisp/dired.el	2012-09-18 23:40:39 +0000
+++ lisp/dired.el	2012-09-20 08:21:11 +0000
@@ -3178,8 +3196,8 @@ (defun dired-toggle-marks ()
 (defvar dired-regexp-history nil
   "History list of regular expressions used in Dired commands.")
 
-(defun dired-read-regexp (prompt)
-  (read-from-minibuffer prompt nil nil nil 'dired-regexp-history))
+(defun dired-read-regexp (prompt &optional default history)
+  (read-regexp prompt default (or history 'dired-regexp-history)))
 
 (defun dired-mark-files-regexp (regexp &optional marker-char)
   "Mark all files matching REGEXP for use in later commands.



PS: The problems related to other arguments (PROMPT and DEFAULT-VALUE)
of `read-regexp' are about to be fixed in bug#12321.

bug#7567: Please add a history argument to read-regexp

[Juri Linkov]

Closed together with bug#12321.