all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
Cc: rms@gnu.org, emacs-devel@gnu.org
Subject: Re: isearch-query-replace-regexp and stuff
Date: 08 Jul 2004 20:12:14 +0200	[thread overview]
Message-ID: <x5zn6a5pxd.fsf@lola.goethe.zz> (raw)
In-Reply-To: <87oemqs8f2.fsf@mail.jurta.org>

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

  reply	other threads:[~2004-07-08 18:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-01 23:18 isearch-query-replace-regexp and stuff David Kastrup
2004-07-02  0:05 ` David Kastrup
2004-07-02 17:51   ` Richard Stallman
2004-07-02  6:55 ` Juri Linkov
2004-07-02  7:55   ` David Kastrup
2004-07-02 13:44     ` Stefan
2004-07-03  6:59     ` Juri Linkov
2004-07-03 18:20 ` Richard Stallman
2004-07-05 19:07   ` David Kastrup
2004-07-06  9:59     ` Juri Linkov
2004-07-06 11:20       ` David Kastrup
2004-07-06 16:36         ` Juri Linkov
2004-07-06 17:29           ` David Kastrup
2004-07-07  5:08             ` Juri Linkov
2004-07-07  9:29               ` David Kastrup
2004-07-07 18:29                 ` Juri Linkov
2004-07-07 19:33                   ` David Kastrup
2004-07-08 16:45                     ` Juri Linkov
2004-07-08 18:12                       ` David Kastrup [this message]
2004-07-09 20:54                         ` Juri Linkov
2004-07-08 23:17                 ` Richard Stallman
2004-07-06 22:00         ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=x5zn6a5pxd.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.