bug#14702: 24.3.50; Byte-compiling called-interactively-p inside catch

[Stephen Berman <stephen.berman@gmx.net>]

On Mon, 24 Jun 2013 21:39:21 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>>    (defun baz ()
>>      (interactive)
>>      (catch 'test
>>        (if (called-interactively-p 'any)
>
> If it hurts, don't do that.
> Internally, the byte-compiled form of catch ends up wrapping its body
> inside a lambda, 

Ah, knowing that I now understand what the disassembled code shows,
which I didn't before, even though there's a hint to that effect in the
Emacs Lisp manual (i.e., "If it is a lambda expression, `disassemble'
compiles it and disassembles the resulting compiled code.").

>                  so the called-interactively-p test refers to the
> implicit lambda added, rather than to the enclosing function
> you defined.
>
> It would be good to avoid this intermediate lambda for performance
> reasons (which would incidentally also fix this particular issue), but
> in the mean time (and more generally) either avoid
> called-interactively-p (pass an extra argument instead), or avoid
> placing it "deep" within your function (e.g. inside
> a catch/unwind-protect/condition-case/save-foobar/...).

At the moment I don't see a way to do either of these: I can't use an
extra argument, because the command where I use called-interactively-p
already uses a prefix argument for another purpose; and I don't see an
alternative to something like `catch', because I need to stop execution
of the command in the middle, when certain conditions obtain (this is my
current fix for the recently reported Todo mode bug -- though I'm trying
to come up with something better, so maybe `catch' will then be
dispensable).

But maybe I can use (eq this-command '<COMMAND-NAME>) instead of
called-interactively-p, since evidently this-command is not effected by
the intervening lambda.  Or can that sexp ever return t when
<COMMAND-NAME> is not called interactively?

Steve Berman