emacs-devel
[Top][All Lists]
Advanced

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

RE: general perform-replace REPLACEMENTS arg for regexpquery-replacement


From: Drew Adams
Subject: RE: general perform-replace REPLACEMENTS arg for regexpquery-replacement?
Date: Tue, 18 Nov 2008 15:20:00 -0800

> >> 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 via email to

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