isearch-query-replace-regexp and stuff

isearch-query-replace-regexp and stuff

[David Kastrup]

As far as I am able to judge from the current code that is just
checked in, if one types M-% from within a regexp isearch or C-M-%
from within an ordinary isearch, the history variable of the last
irrelevant search type gets consulted.

That seems weird.  I think that M-% from within a regexp isearch
should probably use the currently matched string, and C-M-% from
within an ordinary isearch should probably use regexp-quote of the
current search string.

I have no brilliant idea of what to do if we type M-% in a regexp
isearch and there is no currently matched string.  Probably just beep
and refuse, which would also be the sanest option if the regexp is
currently incomplete.  Of course, if query-replace-interactive is
'initial, one might possibly just provide an empty string as initial
value (leaving the history in peace), and if it is nil, we need not
bother anyhow.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: isearch-query-replace-regexp and stuff

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> As far as I am able to judge from the current code that is just
> checked in, if one types M-% from within a regexp isearch or C-M-%
> from within an ordinary isearch, the history variable of the last
> irrelevant search type gets consulted.
> 
> That seems weird.  I think that M-% from within a regexp isearch
> should probably use the currently matched string, and C-M-% from
> within an ordinary isearch should probably use regexp-quote of the
> current search string.

[...]

While we are at it: maybe M-s should turn an ordinary search into a
regexp search (while regexp-quoting the current search string to make
it fitting for a regexp search), and vice versa (by using the
currently matched string, if any, as search string).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: isearch-query-replace-regexp and stuff

[Juri Linkov]

David Kastrup <dak@gnu.org> writes:
> As far as I am able to judge from the current code that is just
> checked in, if one types M-% from within a regexp isearch or C-M-%
> from within an ordinary isearch, the history variable of the last
> irrelevant search type gets consulted.  That seems weird.

That might seem weird, but it allows users to do weird things if they
want so.  Users may want to search with C-s for a regexp in the
buffer and start C-M-% with a regexp copied literally from the search
string.

Actually, I don't know what users may want to do in these two cases
(`C-s string C-M-%' and `C-M-s regexp M-%').  There are too many
possibilities here, so I chose the most straightforward one which is
based with a simple WYSIWYG principle: what you see in the echo area
in isearch mode is what you get as the replacement string.

> I think that M-% from within a regexp isearch should probably use
> the currently matched string, and C-M-% from within an ordinary
> isearch should probably use regexp-quote of the current search
> string.
>
> I have no brilliant idea of what to do if we type M-% in a regexp
> isearch and there is no currently matched string.  Probably just beep
> and refuse, which would also be the sanest option if the regexp is
> currently incomplete.  Of course, if query-replace-interactive is
> 'initial, one might possibly just provide an empty string as initial
> value (leaving the history in peace), and if it is nil, we need not
> bother anyhow.

All this makes sense.  We could implement this for the sake of user
convenience provided that this is what most users would expect, but
often mandatory conveniences are too annoying.

> While we are at it: maybe M-s should turn an ordinary search into a
> regexp search (while regexp-quoting the current search string to make
> it fitting for a regexp search), and vice versa (by using the
> currently matched string, if any, as search string).

Do you propose a new key binding M-s or do you actually mean
modifying the existing M-r?  M-r currently toggles regular-expression
mode, but it neither quotes the regexp nor turns the search regexp
into the matched string.  We could use a prefix argument of M-r
to implement these things instead of adding a new key binding.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-query-replace-regexp and stuff

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> David Kastrup <dak@gnu.org> writes:
> > As far as I am able to judge from the current code that is just
> > checked in, if one types M-% from within a regexp isearch or C-M-%
> > from within an ordinary isearch, the history variable of the last
> > irrelevant search type gets consulted.  That seems weird.
> 
> That might seem weird, but it allows users to do weird things if they
> want so.  Users may want to search with C-s for a regexp in the
> buffer and start C-M-% with a regexp copied literally from the search
> string.

This is not what I guessed from the code, but I might be mistaken.
But I don't consider it likely.  And the same reasoning would hold
that users might want to search with C-u C-s for a regexp and start
C-M-% with regexp copied literally from the search string.  If you
want to start over with something you found, then start over.  It does
not make sense to define some secret switch-horses functionality here.
The other thing that might make sense is to just define M-% and use it
to start regexp replacements in regexp searches, and non-regexp
replaced in normal isearch.  It might be confusing.  OTOH, the C-s
binding during searches already has this sort of split personality.

> > I think that M-% from within a regexp isearch should probably use
> > the currently matched string, and C-M-% from within an ordinary
> > isearch should probably use regexp-quote of the current search
> > string.
> >
> > I have no brilliant idea of what to do if we type M-% in a regexp
> > isearch and there is no currently matched string.  Probably just beep
> > and refuse, which would also be the sanest option if the regexp is
> > currently incomplete.  Of course, if query-replace-interactive is
> > 'initial, one might possibly just provide an empty string as initial
> > value (leaving the history in peace), and if it is nil, we need not
> > bother anyhow.
> 
> All this makes sense.  We could implement this for the sake of user
> convenience provided that this is what most users would expect, but
> often mandatory conveniences are too annoying.

Well, the existing behavior does not seem particularly useful, and
far from obvious.  My proposal has the purpose of keeping a
successful search successful.

> > While we are at it: maybe M-s should turn an ordinary search into
> > a regexp search (while regexp-quoting the current search string to
> > make it fitting for a regexp search), and vice versa (by using the
> > currently matched string, if any, as search string).
> 
> Do you propose a new key binding M-s or do you actually mean
> modifying the existing M-r?  M-r currently toggles regular-expression
> mode, but it neither quotes the regexp nor turns the search regexp
> into the matched string.

Oops, didn't realize that.

> We could use a prefix argument of M-r to implement these things
> instead of adding a new key binding.

No, we couldn't.  Prefix arguments exit the search.  It might make
sense when switching to use the respective search history's last entry
_if_ it happens to match at point.  That way, M-r M-r would be a noop
instead of turning a general regexp into one just matching a string.
OTOH, there is little motivation for typing M-r M-r anyhow.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: isearch-query-replace-regexp and stuff

[Stefan]

> The other thing that might make sense is to just define M-% and use it
> to start regexp replacements in regexp searches, and non-regexp
> replaced in normal isearch.  It might be confusing.  OTOH, the C-s
> binding during searches already has this sort of split personality.

Indeed such a M-% binding is what I've used for the last two years and I've
been pretty happy with it.  But I also find M-C-% to be too hard to type, so
I've rebound it to C-u M-%.

The other difference with the current code is that my isearch-query-replace
function does not exit isearch, so after the query-replace is done you're
back in isearch mode.  But this part of the behavior was a bad idea:
it doesn't hurt but it's useless.


        Stefan

Re: isearch-query-replace-regexp and stuff

[Richard Stallman]

I don't want to make ANY additional characters special in an isearch
without very good reasons.  Certainly not just "while we are at it".

Re: isearch-query-replace-regexp and stuff

[Juri Linkov]

David Kastrup <dak@gnu.org> writes:
> The other thing that might make sense is to just define M-% and use it
> to start regexp replacements in regexp searches, and non-regexp
> replaced in normal isearch.  It might be confusing.  OTOH, the C-s
> binding during searches already has this sort of split personality.

Yes, it makes sense to use M-% to start regexp replacements in regexp
search.  I often mistakenly type M-% even if I want to start regexp
replacements, and then cancel it and retype C-M-%.  Using M-% to start
regexp replacements in regexp isearch will reduce such mistakes.  If
users have switched to regexp search mode there is a high probability
than they want regexp replacements and mistyped M-% instead of C-M-%.

>> We could use a prefix argument of M-r to implement these things
>> instead of adding a new key binding.
>
> No, we couldn't.  Prefix arguments exit the search.

Prefix arguments don't exit the search.  IIRC, this is a relatively
recent change in isearch.el.

> It might make sense when switching to use the respective search
> history's last entry _if_ it happens to match at point.

This is useless.  It's possible to type M-p just after switching
the search mode to use the respective search history's last entry.
But the current non-intrusive behavior of M-r is much better
for users who use it to switch the search type invoked by mistake
(`C-s' instead of `C-M-s') or by other reasons (e.g. want to add
regexp constructs to the current search string).

BTW, M-p currently does not work right.  When typing it after starting
isearch mode (i.e. `C-s M-p') it uses not the most recent item in the
search ring, but the second history item.  The patch below fixes this
problem.  It makes M-p to start visiting previous search strings from
the index 0 instead of 1.  And in those places where the last search
string is reused after typing `C-s C-s' it calls `isearch-ring-adjust1'
to adjust the isearch ring to the first element to prepare the correct
index for further M-p and M-n commands.

Index: lisp/isearch.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.230
diff -u -w -b -r1.230 isearch.el
--- lisp/isearch.el	1 Jul 2004 09:54:51 -0000	1.230
+++ lisp/isearch.el	3 Jul 2004 07:32:43 -0000
@@ -911,6 +911,7 @@
 
 	  ;; Empty isearch-string means use default.
 	  (if (= 0 (length isearch-string))
+	      (progn
 	      (setq isearch-string (or (car (if isearch-regexp
 						regexp-search-ring
 					      search-ring))
@@ -919,6 +920,7 @@
 		    isearch-message
 		    (mapconcat 'isearch-text-char-description
 			       isearch-string ""))
+                (isearch-ring-adjust1 nil))
 	    ;; This used to set the last search string,
 	    ;; but I think it is not right to do that here.
 	    ;; Only the string actually used should be saved.
@@ -989,6 +991,7 @@
       ;; C-s in forward or C-r in reverse.
       (if (equal isearch-string "")
 	  ;; If search string is empty, use last one.
+	  (progn
 	  (setq isearch-string
 		(or (if isearch-regexp
 			(car regexp-search-ring)
@@ -998,6 +1001,7 @@
 		(mapconcat 'isearch-text-char-description
 			   isearch-string "")
 		isearch-case-fold-search isearch-last-case-fold-search)
+            (isearch-ring-adjust1 nil))
 	;; If already have what to search for, repeat it.
 	(or isearch-success
 	    (progn
@@ -1650,11 +1654,10 @@
 	()
       (set yank-pointer-name
 	   (setq yank-pointer
-		 (mod (+ (or yank-pointer 0)
+		 (mod (+ (or yank-pointer (if advance 0 -1))
 			 (if advance -1 1))
 		      length)))
       (setq isearch-string (nth yank-pointer ring)
@@ -1693,13 +1695,11 @@
 	()
       (set yank-pointer-name
 	   (setq yank-pointer
-		 (mod (- (or yank-pointer 0) n)
+		 (mod (- (or yank-pointer (if (> n 0) 0 -1)) n)
 		      length)))

       (delete-field)
       (insert (nth yank-pointer ring))

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-query-replace-regexp and stuff

[Richard Stallman]

    As far as I am able to judge from the current code that is just
    checked in, if one types M-% from within a regexp isearch or C-M-%
    from within an ordinary isearch, the history variable of the last
    irrelevant search type gets consulted.

    That seems weird.  I think that M-% from within a regexp isearch
    should probably use the currently matched string, and C-M-% from
    within an ordinary isearch should probably use regexp-quote of the
    current search string.

I think M-% in string search should do query-replace
and M-% in regexp search should do query-replace-regexp.
That is simple, easy to type, and involves fewer characters.

Re: isearch-query-replace-regexp and stuff

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     As far as I am able to judge from the current code that is just
>     checked in, if one types M-% from within a regexp isearch or C-M-%
>     from within an ordinary isearch, the history variable of the last
>     irrelevant search type gets consulted.
> 
>     That seems weird.  I think that M-% from within a regexp isearch
>     should probably use the currently matched string, and C-M-% from
>     within an ordinary isearch should probably use regexp-quote of the
>     current search string.
> 
> I think M-% in string search should do query-replace
> and M-% in regexp search should do query-replace-regexp.
> That is simple, easy to type, and involves fewer characters.

Agreed.  The change-type-of-search functionality is something weird
enough that one does not want to spend to much time thinking about
how to throw this at the user.

It might be an idea to also bind C-M-% to the same, non-type-switching
behavior for symmetry.  If the user wants to switch behavior, he can
do so with the existing M-r binding.  To make this more useful than
just exiting search and restarting replacement, we might consider
letting M-r in isearches keep the search string if it non-empty.
This might be done in one of several ways:

a) keep the search string unmodified.  This has the advantage that
you can keep already typed search string characters even when you
accidentally started with the wrong search type.

b) start over.  I think this might be the current behavior.  It does
not buy you anything over leaving the current isearch and starting
over with a different one.

c) regexp-quote the search string when going to regexp searches, do
something useful when going backward.  That was my original
proposal.  It has the advantage that an existing match remains an
existing match.

After thinking this over, I think that maybe something like option
"a)" would more often agree with what the user could expect and which
would offer the most _additional_ usefulness.  The main question to
resolve for that would be just _where_ to start looking for the next
match under the changed conditions.  Probably resuming the search from
the last position that _did_ match anything?  That might make sense if
you repeat searching a few times, add something like [ and then notice
(because of a non-match) that you really wanted a regexp search
instead.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: isearch-query-replace-regexp and stuff

[Juri Linkov]

David Kastrup <dak@gnu.org> writes:
> It might be an idea to also bind C-M-% to the same, non-type-switching
> behavior for symmetry.  If the user wants to switch behavior, he can
> do so with the existing M-r binding.

C-M-% is a standard key binding to start regexp replacement,
so it should be available in isearch too.

> To make this more useful than just exiting search and restarting
> replacement, we might consider letting M-r in isearches keep the
> search string if it non-empty.  This might be done in one of several
> ways:
> a) keep the search string unmodified.  This has the advantage that
> you can keep already typed search string characters even when you
> accidentally started with the wrong search type.
> [...]
> After thinking this over, I think that maybe something like option
> "a)" would more often agree with what the user could expect and which
> would offer the most _additional_ usefulness.

AFAIU, option "a)" is exactly the current behavior.  And I think
no improvements are needed here.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-query-replace-regexp and stuff

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> David Kastrup <dak@gnu.org> writes:
> > It might be an idea to also bind C-M-% to the same, non-type-switching
> > behavior for symmetry.  If the user wants to switch behavior, he can
> > do so with the existing M-r binding.
> 
> C-M-% is a standard key binding to start regexp replacement,
> so it should be available in isearch too.

Well, C-s is a standard key binding to start literal searches, so the
same argument would apply for its meaning of continuing a regexp
search.

> > To make this more useful than just exiting search and restarting
> > replacement, we might consider letting M-r in isearches keep the
> > search string if it non-empty.  This might be done in one of
> > several ways: a) keep the search string unmodified.  This has the
> > advantage that you can keep already typed search string characters
> > even when you accidentally started with the wrong search type.
> > [...]  After thinking this over, I think that maybe something like
> > option "a)" would more often agree with what the user could expect
> > and which would offer the most _additional_ usefulness.
> 
> AFAIU, option "a)" is exactly the current behavior.

That's what I get for not trying out things.

> And I think no improvements are needed here.

Well, if I do
C-s e[e] M-r
on this mail, then a "failed isearch" turns into a "failed regexp
isearch" until I press C-s again.  While this has the advantage that
M-r M-r is a noop, it seems counterintuitive.  Maybe switching with
M-r should do something like the following?

If looking-at (or its non-regexp equivalent) returns non-nil after the
change, remove a potentially previous "failed" tag.  If looking-at
returns nil, call the search "pending" instead of "failed" until C-s
is pressed again.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: isearch-query-replace-regexp and stuff

[Juri Linkov]

David Kastrup <dak@gnu.org> writes:
> Juri Linkov <juri@jurta.org> writes:
>> C-M-% is a standard key binding to start regexp replacement,
>> so it should be available in isearch too.
>
> Well, C-s is a standard key binding to start literal searches, so the
> same argument would apply for its meaning of continuing a regexp
> search.

This analogy is appropriate (even C-M-s can continue a non-regexp
search), but at the same time I think no one would have an incentive
to type C-M-% in a non-regexp search to start a non-regexp replacement.
C-M-% is quite hard to type, and if someone still decided to type it,
this means only that it was typed with the intention to start a regexp
replacement.

> Well, if I do
> C-s e[e] M-r
> on this mail, then a "failed isearch" turns into a "failed regexp
> isearch" until I press C-s again. While this has the advantage that
> M-r M-r is a noop, it seems counterintuitive.  Maybe switching with
> M-r should do something like the following?
>
> If looking-at (or its non-regexp equivalent) returns non-nil after the
> change, remove a potentially previous "failed" tag.  If looking-at
> returns nil, call the search "pending" instead of "failed" until C-s
> is pressed again.

Maybe it's better to always clear the failed flag after switching
with M-r, because repeating the failed search after switching the
search type has such undesirable behavior as wrapping the search and
starting from the beginning of the buffer.  After switching the search
type it should continue from the same point even if the previous search
type failed.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-query-replace-regexp and stuff

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> David Kastrup <dak@gnu.org> writes:
> > Juri Linkov <juri@jurta.org> writes:
> >> C-M-% is a standard key binding to start regexp replacement,
> >> so it should be available in isearch too.
> >
> > Well, C-s is a standard key binding to start literal searches, so the
> > same argument would apply for its meaning of continuing a regexp
> > search.
> 
> This analogy is appropriate (even C-M-s can continue a non-regexp
> search), but at the same time I think no one would have an incentive
> to type C-M-% in a non-regexp search to start a non-regexp replacement.

So what incentive would there be to continue a non-regexp search with
C-M-s?  The point is that it makes sense to make the bindings
identical in regexp searches, so it would be strange to separate them
again in non-regexp searches.

> C-M-% is quite hard to type, and if someone still decided to type
> it, this means only that it was typed with the intention to start a
> regexp replacement.

C-M-s is quite hard to type, and if someone still decided to type it,
this means only that it was typed with the intention to start a
regexp search.

In short: you are arguing against consistency.

> > Well, if I do C-s e[e] M-r on this mail, then a "failed isearch"
> > turns into a "failed regexp isearch" until I press C-s
> > again. While this has the advantage that M-r M-r is a noop, it
> > seems counterintuitive.  Maybe switching with M-r should do
> > something like the following?
> >
> > If looking-at (or its non-regexp equivalent) returns non-nil after the
> > change, remove a potentially previous "failed" tag.  If looking-at
> > returns nil, call the search "pending" instead of "failed" until C-s
> > is pressed again.
> 
> Maybe it's better to always clear the failed flag after switching
> with M-r, because repeating the failed search after switching the
> search type has such undesirable behavior as wrapping the search and
> starting from the beginning of the buffer.

Well, my proposal would not have "failed" in the display after the
switch, so it would be natural not to have the flag set, either.  The
question is just whether one should change the display to "pending"
to indicate this change, or simply don't mention this somewhat
peculiar state at all.

> After switching the search type it should continue from the same
> point even if the previous search type failed.

Definitely.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: isearch-query-replace-regexp and stuff

[Richard Stallman]

    If looking-at (or its non-regexp equivalent) returns non-nil after the
    change, remove a potentially previous "failed" tag.  If looking-at
    returns nil, call the search "pending" instead of "failed" until C-s
    is pressed again.

I think you're suggesting a change only in what gets displayed
in the echo area.  If I understand right, it seems good to me.

Re: isearch-query-replace-regexp and stuff

[Juri Linkov]

David Kastrup <dak@gnu.org> writes:
> C-M-s is quite hard to type, and if someone still decided to type it,
> this means only that it was typed with the intention to start a
> regexp search.

Exactly!

The current behavior of C-M-s to repeat the non-regexp search is not
the most reasonable one.  More correct would be to switch the search
to regexp mode before doing the search again.  I guess it works now
that way because it was simpler to implement and nobody cared about
handling this case specially.  But we could change the behavior of C-M-s
in non-regexp mode to switch to regexp mode for consistency with C-M-%.

> Well, my proposal would not have "failed" in the display after the
> switch, so it would be natural not to have the flag set, either.  The
> question is just whether one should change the display to "pending"
> to indicate this change, or simply don't mention this somewhat
> peculiar state at all.

While looking at isearch.el I noticed that `isearch-toggle-case-fold'
already sets the `isearch-adjusted' flag.  It seems the purpose of
this variable exactly fits into your proposal.  We could set it in
`isearch-toggle-regexp' and display "pending" in the echo area.
That way both `isearch-toggle-regexp' and `isearch-toggle-case-fold'
will be equivalent w.r.t. treating of inconsistent state after
switching between case or regexp modes.

Index: lisp/isearch.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/isearch.el,v
retrieving revision 1.230
diff -u -r1.230 isearch.el
--- lisp/isearch.el	1 Jul 2004 09:54:51 -0000	1.230
+++ lisp/isearch.el	7 Jul 2004 03:33:21 -0000
@@ -1043,6 +1043,7 @@
   (interactive)
   (setq isearch-regexp (not isearch-regexp))
   (if isearch-regexp (setq isearch-word nil))
+  (setq isearch-success t isearch-adjusted t)
   (isearch-update))
 
 (defun isearch-toggle-case-fold ()
@@ -1055,33 +1056,27 @@
 	     (isearch-message-prefix nil nil isearch-nonincremental)
 	     isearch-message
 	     (if isearch-case-fold-search "in" "")))
-  (setq isearch-adjusted t)
+  (setq isearch-success t isearch-adjusted t)
   (sit-for 1)
   (isearch-update))
 
@@ -1841,6 +1836,7 @@
   ;; If currently failing, display no ellipsis.
   (or isearch-success (setq ellipsis nil))
   (let ((m (concat (if isearch-success "" "failing ")
+                   (if isearch-adjusted "pending " "")
 		   (if (and isearch-wrapped
 			    (if isearch-forward
 				(> (point) isearch-opoint)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-query-replace-regexp and stuff

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> David Kastrup <dak@gnu.org> writes:
> > C-M-s is quite hard to type, and if someone still decided to type it,
> > this means only that it was typed with the intention to start a
> > regexp search.
> 
> Exactly!
> 
> The current behavior of C-M-s to repeat the non-regexp search is not
> the most reasonable one.  More correct would be to switch the search
> to regexp mode before doing the search again.  I guess it works now
> that way because it was simpler to implement and nobody cared about
> handling this case specially.  But we could change the behavior of
> C-M-s in non-regexp mode to switch to regexp mode for consistency
> with C-M-%.

But that's inconsistent with being able to use both C-s and M-C-s in
regexp searches.

Don't you see that?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: isearch-query-replace-regexp and stuff

[Juri Linkov]

David Kastrup <dak@gnu.org> writes:
> Juri Linkov <juri@jurta.org> writes:
>> The current behavior of C-M-s to repeat the non-regexp search is not
>> the most reasonable one.  More correct would be to switch the search
>> to regexp mode before doing the search again.  I guess it works now
>> that way because it was simpler to implement and nobody cared about
>> handling this case specially.  But we could change the behavior of
>> C-M-s in non-regexp mode to switch to regexp mode for consistency
>> with C-M-%.
>
> But that's inconsistent with being able to use both C-s and M-C-s in
> regexp searches.
>
> Don't you see that?

You can see the following comments for `isearch-mode-map' in isearch.el
(underlining is mine):

    ;; Define M-C-s and M-C-r like C-s and C-r so that the same key
    ;; combinations can be used to repeat regexp isearches that can
                                          ================
    ;; be used to start these searches.

So the meaning of C-M-s in a non-regexp search is still undefined,
and the fact that C-M-s can repeat a non-regexp search is a side effect
of the current implementation.

And there is no symmetry between normal and regexp searches and it
doesn't need to be.  The regexp search C-M-s is regarded everywhere
in Emacs as a specific type of more general C-s search per se.  So
there is no need to keep symmetry for C-M-s in a normal search with
C-M-s in a regexp search.

And moreover, more appropriate action for C-M-s in a normal search is
to switch the search to regexp mode because the Meta key in C-M-s
has an strong association with a specific regexp search type.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-query-replace-regexp and stuff

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> David Kastrup <dak@gnu.org> writes:
> > Juri Linkov <juri@jurta.org> writes:
> >> The current behavior of C-M-s to repeat the non-regexp search is not
> >> the most reasonable one.  More correct would be to switch the search
> >> to regexp mode before doing the search again.  I guess it works now
> >> that way because it was simpler to implement and nobody cared about
> >> handling this case specially.  But we could change the behavior of
> >> C-M-s in non-regexp mode to switch to regexp mode for consistency
> >> with C-M-%.
> >
> > But that's inconsistent with being able to use both C-s and M-C-s in
> > regexp searches.
> >
> > Don't you see that?
> 
> You can see the following comments for `isearch-mode-map' in isearch.el
> (underlining is mine):
> 
>     ;; Define M-C-s and M-C-r like C-s and C-r so that the same key
>     ;; combinations can be used to repeat regexp isearches that can
>                                           ================
>     ;; be used to start these searches.
> 
> So the meaning of C-M-s in a non-regexp search is still undefined,

Because of some internal comment?

> and the fact that C-M-s can repeat a non-regexp search is a side
> effect of the current implementation.

If you want to call explicitly coded "consistency" a side effect.

> And there is no symmetry between normal and regexp searches

Not?  Considering that both behave the same with regard to C-s and
C-M-s I would think there was.  And intentionally so.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: isearch-query-replace-regexp and stuff

[Juri Linkov]

David Kastrup <dak@gnu.org> writes:
> Juri Linkov <juri@jurta.org> writes:
>> David Kastrup <dak@gnu.org> writes:
>> > Juri Linkov <juri@jurta.org> writes:
>> >> The current behavior of C-M-s to repeat the non-regexp search is not
>> >> the most reasonable one.  More correct would be to switch the search
>> >> to regexp mode before doing the search again.  I guess it works now
>> >> that way because it was simpler to implement and nobody cared about
>> >> handling this case specially.  But we could change the behavior of
>> >> C-M-s in non-regexp mode to switch to regexp mode for consistency
>> >> with C-M-%.
>> >
>> > But that's inconsistent with being able to use both C-s and M-C-s in
>> > regexp searches.
>> >
>> > Don't you see that?
>> 
>> You can see the following comments for `isearch-mode-map' in isearch.el
>> (underlining is mine):
>> 
>>     ;; Define M-C-s and M-C-r like C-s and C-r so that the same key
>>     ;; combinations can be used to repeat regexp isearches that can
>>                                           ================
>>     ;; be used to start these searches.
>> 
>> So the meaning of C-M-s in a non-regexp search is still undefined,
>
> Because of some internal comment?

There is no other source of information about the current implementation,
but this comment explicitly states the intention of introducing those
keybindings.  The intention was to allow to repeat regexp isearches
with the same key that started these searches.

>> and the fact that C-M-s can repeat a non-regexp search is a side
>> effect of the current implementation.
>
> If you want to call explicitly coded "consistency" a side effect.

The current behavior is a consequence of a simpler implementation
that ignores the case of using C-M-s in normal searches as unimportant.

>> And there is no symmetry between normal and regexp searches
>
> Not?  Considering that both behave the same with regard to C-s and
> C-M-s I would think there was.  And intentionally so.

According to comments in isearch.el (supposedly written by authors of
the current implementation) it is not intentional.

Anyway, I don't want to make C-M-% consistent with accidental features,
but what I want is to make it more convenient.  Invoking `query-replace-regexp'
makes sense even in a non-regexp search for the sake of using features
available only in regexp replacements (like using \# and \,), for example:

C-s foo C-M-% \&<\#> RET

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: isearch-query-replace-regexp and stuff

[David Kastrup]

Juri Linkov <juri@jurta.org> writes:

> David Kastrup <dak@gnu.org> writes:
> >
> > Because of some internal comment?
> 
> There is no other source of information about the current
> implementation, but this comment explicitly states the intention of
> introducing those keybindings.

A code comment is completely irrelevant for deciding about the best
way to do something unless you happen to consider the writer of the
comment a superior being whose intent you need to cast upon the
user.  Things are slightly different with regard to actual
user-accessible documentation: there the user might have been exposed
to it already if it has persisted for some time.

> The current behavior is a consequence of a simpler implementation
> that ignores the case of using C-M-s in normal searches as
> unimportant.

It is unimportant.

> >> And there is no symmetry between normal and regexp searches
> >
> > Not?  Considering that both behave the same with regard to C-s and
> > C-M-s I would think there was.  And intentionally so.
> 
> According to comments in isearch.el (supposedly written by authors
> of the current implementation) it is not intentional.

I can't see any comment that would state a different intention.

> Anyway, I don't want to make C-M-% consistent with accidental
> features, but what I want is to make it more convenient.  Invoking
> `query-replace-regexp' makes sense even in a non-regexp search for
> the sake of using features available only in regexp replacements
> (like using \# and \,), for example:
> 
> C-s foo C-M-% \&<\#> RET

C-s foo M-r C-% \&<\#> RET

Hardly more complicated.  The problem is that switching from regexp
searches to non-regexp searches buys us problems with the validity of
the search string.  With M-r, we have _one_ point to deal with them,
M-r itself.  And we are just now discussing how to turn this into
something visible and coherent.

If we add an implicit and unsymmetric one-way to switch to
regexp-matching as well as replacement, we don't have the opportunity
to announce to the user that a switch has happened and is causing a
difference.

And how would you want to write this in the manual?

"You can use either M-% or C-M-% in a regexp isearch to do a regexp
replacement, but only M-% will do a plain replacement in normal
isearch whereas C-M-% will switch to a regexp replacement, while the
current match will not [or maybe will?] get quotified so the match
does not stop for future replacements".

That's a bunch of crock.  It is not worth the price in obscurity,
just to save the user from pressing one additional key.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: isearch-query-replace-regexp and stuff

[Richard Stallman]

Let's not spend any more time arguing about what C-M-s inside a search
should do.  The question is not worth the time people have already
spend on it.  There is no need to change it, so we will leave it the
way it is.

Re: isearch-query-replace-regexp and stuff

[Juri Linkov]

David Kastrup <dak@gnu.org> writes:
> And how would you want to write this in the manual?
>
> "You can use either M-% or C-M-% in a regexp isearch to do a regexp
> replacement, but only M-% will do a plain replacement in normal
> isearch whereas C-M-% will switch to a regexp replacement, while the
> current match will not [or maybe will?] get quotified so the match
> does not stop for future replacements".
>
> That's a bunch of crock.  It is not worth the price in obscurity,
> just to save the user from pressing one additional key.

But information about pressing that additional key to switch the
search to regexp mode to start a regexp replacement should be
documented in the manual too.

Anyway, I looked at the problem from the user's point of view and
allowing C-M-% to call a regexp replacement in normal isearch was
based on the simple premise: it is natural for Emacs users to expect
that typing C-M-% regardless of search type (regexp or normal) will
start a regexp replacement with the from-string taken from the search
string displayed in the isearch echo area.  And it is the responsibility
of the user to guarantee that the search string before typing C-M-% is
literally the same as the user intended to use it for the from-string
argument of a regexp replacement.

If you agree with this, appropriately writing this in the manual might
not look too ugly.  If not, it's not a big problem not to bind C-M-%
to a regexp replacement in normal isearch.

-- 
Juri Linkov
http://www.jurta.org/emacs/