From: "Drew Adams" <drew.adams@oracle.com>
To: "Emacs-Devel" <emacs-devel@gnu.org>
Subject: RE: should query-replace-regexp-eval be in the manual?
Date: Sun, 15 Apr 2007 15:54:58 -0700 [thread overview]
Message-ID: <EIENLHALHGIMHGDOLMIMKEKIDAAA.drew.adams@oracle.com> (raw)
In-Reply-To: <85ejmlwbd8.fsf@lola.goethe.zz>
> > For those who are familiar with this command and with using `\,' with
> > `query-replace-regexp': Could you compare/contrast these two in
> > terms of use cases?
>
> query-replace-regexp-eval can do nothing that one can't achieve with a
> use of a \, expression in query-replace-regexp.
>
> In contrast to query-replace-regexp-eval, \, does not necessitate
> deciding in advance that you are going to need Lisp for a job, and
> you'll only need to use Lisp for those parts of the expression where
> it is necessary.
>
> I came up with the idea of \, after stumbling upon
> query-replace-regexp-eval and noticing that the typical usage pattern
> was to start something with C-M-%, type stuff into it, then do a
> combination of C-k, C-g, C-M-Esc or other things I don't remember
> right now, in order to restart the whole process using
> query-replace-regexp-eval instead. And query-replace-regexp-eval does
> not have a keybinding of its own.
>
> Basically it has been my experience that query-replace-regexp-eval is
> a nice idea, but in practice quite unusable. \, achieves a similar
> purpose but with a much more convenient interface.
That's pretty much what I expected, but I wasn't sure if I wasn't perhaps
missing something.
> To get back to the original question: since \, has all of the
> functionality of query-replace-regexp-eval with a more convenient
> interface, query-replace-regexp-eval could be considered obsolete or
> at least obscure.
In that case, why keep `query-replace-regexp-eval'? You seem to be saying
that there really is no separate use case for it. That's an argument for
deprecating it.
The (minor) advantage I see for it is the case that you hint at: It saves
having to use the `\,...' syntax, when you know that you want Lisp
evaluation (and only Lisp evaluation, for the entire replacement).
That is, the interface of `query-replace-regexp' is more convenient _in
general_, because it is more general and flexible. But it requires extra
syntax (`\,...') whenever you want only Lisp eval. For that reason, someone
might want to bind `query-replace-regexp-eval' to a key, to save some extra
syntax (`\,...').
I think that these are the only reasonable options:
1. Get rid of `query-replace-regexp-eval', since you can always use the
`\,...' syntax to get the same effect (and more).
2. Keep `query-replace-regexp-eval', and mention in its doc string that it
is a shortcut that gives the effect of using `query-replace-regexp' with
(only) `\,...'.
If we choose #2, then the question is whether to mention
`query-replace-regexp-eval' in the manual. It's not strictly needed, because
users can find it via `apropos'.
> Since we tell people how to do the same thing more flexibly with \, I
> don't think that query-replace-regexp-eval deserves a place in the
> manual. It would be a lot of additional explanation without any
> conceivable benefit to the user.
On the other hand, it could be described briefly in the manual in this way,
and that might make things clearer:
`query-replace-regexp-eval' - Query-replace text that matches
a regexp by the result of evaluating a Lisp sexp, taken as
a string. You are prompted for the regexp and the sexp. You
can get the same effect by using the more general command
`query-replace-regexp', enclosing the sexp within `\,...'.
That makes clear what it does, and what its specific use case is. And it is
not "a lot of additional explanation".
I won't argue strongly for inclusion in the manual. But I will point out
that "more flexibly" comes at the (minor) cost of using extra syntax for
simple eval-only cases, and not bothering with that syntax can be a (minor)
convenience - that's a user choice.
I vote for 1) keeping it and 2) documenting it in the terms mentioned above.
BTW, `query-replace-regexp', with `\,...' and all the rest, is one of the
truly great features offered in Emacs 22, IMO. Bravo!
next prev parent reply other threads:[~2007-04-15 22:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-13 16:41 should query-replace-regexp-eval be in the manual? Drew Adams
2007-04-14 9:47 ` Alan Mackenzie
2007-04-14 14:43 ` Drew Adams
2007-04-15 21:56 ` David Kastrup
2007-04-15 22:03 ` David Kastrup
2007-04-15 22:11 ` Lennart Borgman (gmail)
2007-04-15 22:55 ` Drew Adams
2007-04-16 0:51 ` Robert J. Chassell
2007-04-16 3:45 ` Stefan Monnier
2007-04-15 22:54 ` Drew Adams [this message]
2007-04-16 15:37 ` Richard Stallman
2007-04-16 17:22 ` David Kastrup
2007-04-17 18:03 ` Richard Stallman
2007-04-17 23:27 ` David Kastrup
2007-04-18 14:56 ` Richard Stallman
2007-04-18 16:37 ` David Kastrup
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=EIENLHALHGIMHGDOLMIMKEKIDAAA.drew.adams@oracle.com \
--to=drew.adams@oracle.com \
--cc=emacs-devel@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.