[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: isearch-query-replace-regexp and stuff

From: David Kastrup
Subject: Re: isearch-query-replace-regexp and stuff
Date: 08 Jul 2004 20:12:14 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Juri Linkov <address@hidden> writes:

> David Kastrup <address@hidden> 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]