unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Juri Linkov'" <juri@jurta.org>
Cc: emacs-devel@gnu.org
Subject: RE: general perform-replace REPLACEMENTS arg for regexpquery-replacement?
Date: Tue, 18 Nov 2008 15:20:00 -0800	[thread overview]
Message-ID: <001701c949d4$2e1d5b20$0200a8c0@us.oracle.com> (raw)
In-Reply-To: <871vx865ld.fsf@jurta.org>

> >> The only place currently preventing this is 
> >> prin1-to-string that turns a list into a string.
> >> We could change it to keep the list intact.
> >
> > Yes, but then you lose the ability to get the current 
> > behavior: replace by the string, "(\"zzz\" \"aaa\")".
> 
> When you want to replace by the string, you don't need `\,'.

What if it's \,(list "zzz" "aaa") or some hairy sexp that evals to the same list
("zzz" "aaa")? You snipped the part about the string being the result of Lisp
evaluation. Currently \, evals the sexp that follows it and then
`prin1-to-string's it to come up with a replacement string.

Is that a useful feature: being able to replace text by the print representation
of a Lisp value that is the result of evaluation? If so, shouldn't it still be
allowed in case the result of evaluation is a list of strings?

I'm not sure it's super important as a feature, but why not keep it? Why lose
that just to favor a particular syntax choice?

I don't feel strongly about that existing feature, and I don't feel strongly
about which syntax we use. I am in favor of the new feature I proposed. Beyond
that, I would point out that, IIUC, what you suggest means losing some current
functionality. That's all.

> > IMO, two different syntaxes are needed to separate the two 
> > different user intentions: a sexp that evals to a string "(...)"
> > and a sexp that evals to a list of strings to pass to
> > `perform-replace'.
> 
> There two syntaxes naturally are `\,(' and `\,'('.

Perhaps we're miscommunicating. \, evals the sexp that follows it. In your first
case, the sexp is presumably a function application or (). In your second case,
the sexp is a quoted list.

What should \, then do with the result of evaluation? Currently \, just uses
prin1 to convert the result to a string to use as replacement. Would you have it
do something different depending on the type of evaluation result?

Would you have it always pass the result on to `perform-replace', as is,
whenever it is a list of strings, but otherwise convert it to a string (as now)?
That is, would you treat \,(list "a" "b") and \,'("a" "b") the same (pass two
replacement strings to perform-replace) but different from \,(list 2 3) (pass
the single string "(2 3)" to perform-replace)?

That doesn't sound too reasonable to me.

Or are you suggesting to explicitly look for the ( and '( as part of the \,
syntax? Do you mean that \,'( would always pass the list that is quoted to
`perform-replace', and never convert it to a string for replacement? If so,
would you check whether the list elements were strings? Or would you always
convert the elements in the quoted list to strings to be sure, so that \,'(2 3)
would pass the list of replacement strings ("2" "3")?

Just what you're proposing is not clear. If it's something like what I've
guessed above, then I'd say:

(1) The expressions will be less readable than if we more clearly separate the
two syntax possibilities, instead of trying to use \, to introduce both.

(2) Its use will be error-prone, because of the similarity in appearance.

Maybe you can give a concrete example or two, to make clear what you're saying.

I'm open on (1) the syntax to use and (2) whether or not to keep the current
possibility of evaling to a Lisp value and then prin1-ing that to a replacement
string - including in the case where the eval result is a list of strings.

I'd prefer a clean separation of syntax: \, for Lisp evaluation and
`prin1-to-string' conversion (always), and something else (dissimilar visually)
for passing a list of strings to `perform-replace'. 

I proposed \@ and later \( for the latter, but I don't much care what we pick. I
don't however favor something that starts, as does Lisp evaluation, with \, -
too confusing for users, too complex as code, and seemingly a loss of some
current functionality. And I don't see any advantage from such a choice.







      reply	other threads:[~2008-11-18 23:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-15 18:43 general perform-replace REPLACEMENTS arg for regexp query-replacement? Drew Adams
2008-11-15 22:31 ` general perform-replace REPLACEMENTS arg for regexpquery-replacement? Drew Adams
2008-11-16 22:34   ` Juri Linkov
2008-11-17  1:25     ` Drew Adams
2008-11-17 22:51       ` Juri Linkov
2008-11-18  1:01         ` Drew Adams
2008-11-18 22:18           ` Juri Linkov
2008-11-18 23:20             ` Drew Adams [this message]

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to='001701c949d4$2e1d5b20$0200a8c0@us.oracle.com' \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=juri@jurta.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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).