bug#15836: 24.3; query-replace-regexp does not detect incorrect usage of \#

bug#15836: 24.3; query-replace-regexp does not detect incorrect usage of \#

[Marcin Kasperski]

I made mistake while entering regexp replacement, and got very
confusing error message.

Try the following: enter non-empty buffer and

   M-x query-replace-regexp
   ^
   \,(\#)

{ I  got this after correcting from earlier used \,(+ 1 \#)  }

Effect: 

   Symbol's function definition is void: replace-count

(which made me look for uninstalled libraries, spoiled files etc)

Expected effect:

   Some error pointing on regexp syntax.

GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.6.4)
 of 2013-10-03 on louvi, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11303000
System Description:	Ubuntu 13.04

-- 

bug#15836: 24.3; query-replace-regexp does not detect incorrect usage of \#

[Glenn Morris]

Marcin Kasperski wrote:

>    M-x query-replace-regexp
>    ^
>    \,(\#)
[...]
>    Symbol's function definition is void: replace-count
>
> (which made me look for uninstalled libraries, spoiled files etc)
>
> Expected effect:
>
>    Some error pointing on regexp syntax.

I'm not sure how to make this any better. You basically got exactly what
you asked for, given how it's documented to work:

    In interactive calls, the replacement text may contain `\,' followed
    by a Lisp expression used as part of the replacement text. [...]
    `\#' itself [stands] for `replace-count', the number of replacements
    occurred so far

So you wrote:

(replace-count)

which is indeed not a function.


The error message could perhaps be wrapped in "Error evaluating
replacement expression: <actual error message>"; but I'm not sure that
would have helped you decide whether it was an internal issue or a
mistake on your part. Special-casing your particular error does not seem
worth it to me.

bug#15836: 24.3; query-replace-regexp does not detect incorrect usage of \#

[Glenn Morris]

Hmm, perhaps replace-eval-replacement could temporarily bind
the function definition of replace-count to some informative error
message ("\# used in function context")?

bug#15836: 24.3; query-replace-regexp does not detect incorrect usage of \#

[Stefan Monnier]

> Hmm, perhaps replace-eval-replacement could temporarily bind
> the function definition of replace-count to some informative error
> message ("\# used in function context")?

Sorry, I don't like this idea.  Much too specific to the particular way
the user screwed up.

I guess we could byte-compile the expression, which would give the user
actual warnings about his code before running it, but I'm afraid this
medicine would be worse than the disease.

Another approach would be to refrain from substituting \# and
instead to let-bind it during the evaluation.


        Stefan

bug#15836: 24.3; query-replace-regexp does not detect incorrect usage of \#

[Marcin Kasperski]

"Error evaluating replacement expression: ... " would be a bit better,
it would point toward replacement expression as something suspicious.


On Sat, Nov 9, 2013 at 12:15 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Hmm, perhaps replace-eval-replacement could temporarily bind
>> the function definition of replace-count to some informative error
>> message ("\# used in function context")?
>
> Sorry, I don't like this idea.  Much too specific to the particular way
> the user screwed up.
>
> I guess we could byte-compile the expression, which would give the user
> actual warnings about his code before running it, but I'm afraid this
> medicine would be worse than the disease.
>
> Another approach would be to refrain from substituting \# and
> instead to let-bind it during the evaluation.
>
>
>         Stefan

bug#15836: 24.3; query-replace-regexp does not detect incorrect usage of \#

[Glenn Morris]

Marcin Kasperski wrote:

> "Error evaluating replacement expression: ... " would be a bit better,
> it would point toward replacement expression as something suspicious.

OK, done.

Not sure anything else can usefully be done, so will probably close this
at some point unless a good idea comes up.