emacs-devel
[Top][All Lists]
Advanced

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




reply via email to

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