[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14702: 24.3.50; Byte-compiling called-interactively-p inside catch
From: |
Stephen Berman |
Subject: |
bug#14702: 24.3.50; Byte-compiling called-interactively-p inside catch |
Date: |
Tue, 25 Jun 2013 15:56:13 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
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