GNU bug report logs - #7567
Please add a history variable to read-regexp

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7567 in the body.
You can then email your comments to 7567 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Emacs Bugs <bug-gnu-emacs <at> gnu.org>
Subject: Please add a history variable to read-regexp
Date: Mon, 6 Dec 2010 03:24:01 +0100

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

Message #8 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: 7567 <at> debbugs.gnu.org
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Mon, 6 Dec 2010 23:43:04 +0100

On Mon, Dec 6, 2010 at 3:24 AM, Lennart Borgman
<lennart.borgman <at> 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.

Message #11 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Lennart Borgman'" <lennart.borgman <at> gmail.com>, <7567 <at> debbugs.gnu.org>
Subject: RE: bug#7567: Please add a history variable to read-regexp
Date: Mon, 6 Dec 2010 14:57:40 -0800

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

Message #14 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 7567 <at> debbugs.gnu.org
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Tue, 7 Dec 2010 00:00:44 +0100

On Mon, Dec 6, 2010 at 11:57 PM, Drew Adams <drew.adams <at> 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.)

Message #17 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 7567 <at> debbugs.gnu.org
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Mon, 06 Dec 2010 23:03:32 +0000

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

Message #20 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Lennart Borgman'" <lennart.borgman <at> gmail.com>
Cc: 7567 <at> debbugs.gnu.org
Subject: RE: bug#7567: Please add a history variable to read-regexp
Date: Mon, 6 Dec 2010 15:11:53 -0800

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

Message #23 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 7567 <at> debbugs.gnu.org
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Tue, 7 Dec 2010 00:23:08 +0100

On Tue, Dec 7, 2010 at 12:11 AM, Drew Adams <drew.adams <at> 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.

Message #26 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 7567 <at> debbugs.gnu.org
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Tue, 7 Dec 2010 00:46:45 +0100

On Tue, Dec 7, 2010 at 12:03 AM, Juri Linkov <juri <at> 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.

Message #29 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Lennart Borgman'" <lennart.borgman <at> gmail.com>
Cc: 7567 <at> debbugs.gnu.org
Subject: RE: bug#7567: Please add a history variable to read-regexp
Date: Mon, 6 Dec 2010 16:31:12 -0800

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

Message #32 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 7567 <at> debbugs.gnu.org
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Mon, 06 Dec 2010 22:48:28 -0500

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

Message #35 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Lennart Borgman'" <lennart.borgman <at> gmail.com>
Cc: 7567 <at> debbugs.gnu.org
Subject: RE: bug#7567: Please add a history variable to read-regexp
Date: Mon, 6 Dec 2010 20:09:55 -0800

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

Message #38 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 7567 <at> debbugs.gnu.org, 'Lennart Borgman' <lennart.borgman <at> gmail.com>
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Wed, 08 Dec 2010 01:51:47 +0000

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

Message #41 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7567 <at> debbugs.gnu.org, Lennart Borgman <lennart.borgman <at> gmail.com>
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Wed, 08 Dec 2010 01:57:11 +0000

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

Message #44 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 7567 <at> debbugs.gnu.org
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Wed, 08 Dec 2010 01:44:22 +0000

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

Message #47 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 7567 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Wed, 8 Dec 2010 03:19:47 +0100

On Wed, Dec 8, 2010 at 2:57 AM, Juri Linkov <juri <at> 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.)

Message #50 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juri Linkov'" <juri <at> jurta.org>
Cc: 7567 <at> debbugs.gnu.org, 'Lennart Borgman' <lennart.borgman <at> gmail.com>
Subject: RE: bug#7567: Please add a history variable to read-regexp
Date: Tue, 7 Dec 2010 19:03:47 -0800

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

Message #53 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Juri Linkov'" <juri <at> jurta.org>,
	"'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 7567 <at> debbugs.gnu.org
Subject: RE: bug#7567: Please add a history variable to read-regexp
Date: Tue, 7 Dec 2010 19:10:07 -0800

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

Message #56 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
	Drew Adams <drew.adams <at> oracle.com>
Cc: 7567 <at> debbugs.gnu.org
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Wed, 8 Dec 2010 04:32:37 +0100

On Tue, Dec 7, 2010 at 4:48 AM, Stefan Monnier <monnier <at> 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.

Message #59 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 7567 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Thu, 09 Dec 2010 01:25:56 +0000

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

Message #62 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: 7567 <at> debbugs.gnu.org, Lennart Borgman <lennart.borgman <at> gmail.com>
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Thu, 09 Dec 2010 09:28:16 -0500

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

Message #65 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Juri Linkov' <juri <at> jurta.org>, 7567 <at> debbugs.gnu.org
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Thu, 09 Dec 2010 09:31:44 -0500

> 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

Message #68 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 'Juri Linkov' <juri <at> jurta.org>, 7567 <at> debbugs.gnu.org
Subject: RE: bug#7567: Please add a history variable to read-regexp
Date: Thu, 9 Dec 2010 08:14:01 -0800

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

Message #71 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>,
	"'Juri Linkov'" <juri <at> jurta.org>
Cc: 7567 <at> debbugs.gnu.org
Subject: RE: bug#7567: Please add a history variable to read-regexp
Date: Thu, 9 Dec 2010 09:43:16 -0800

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

Message #74 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Juri Linkov' <juri <at> jurta.org>, 7567 <at> debbugs.gnu.org
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Thu, 09 Dec 2010 22:06:45 -0500

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

Message #77 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Juri Linkov' <juri <at> jurta.org>, 7567 <at> debbugs.gnu.org
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Thu, 09 Dec 2010 22:09:36 -0500

> 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

Message #80 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 'Juri Linkov' <juri <at> jurta.org>, 7567 <at> debbugs.gnu.org
Subject: RE: bug#7567: Please add a history variable to read-regexp
Date: Thu, 9 Dec 2010 19:46:23 -0800

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

Message #83 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Drew Adams" <drew.adams <at> oracle.com>
Cc: 'Juri Linkov' <juri <at> jurta.org>, 7567 <at> debbugs.gnu.org
Subject: Re: bug#7567: Please add a history variable to read-regexp
Date: Fri, 10 Dec 2010 15:10:05 -0500

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

Message #86 received at 7567 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: 7567 <at> debbugs.gnu.org
Subject: Re: bug#7567: Please add a history argument to read-regexp
Date: Thu, 20 Sep 2012 11:30:35 +0300

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.

Message #91 received at 7567-done <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: 7567-done <at> debbugs.gnu.org
Subject: Re: bug#7567: Please add a history argument to read-regexp
Date: Fri, 21 Sep 2012 00:59:18 +0300

Closed together with bug#12321.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.