Re: Brittleness of called-interactively-p

[Dmitri Paduchikh <dpaduchikh@gmail.com>]

Richard Stallman <rms@gnu.org> writes:

RS> Here's another approach: give 'interactive' a way to specify a variable
RS> to bind for this purpose. That way, the variable would be bound only in
RS> functions that want it, and it would not interfere with the function's
RS> calling interface.

It is not clear for me whether this approach will help to solve the current
problem of macros wrapping fragments of code in lambdas.

[...]

RS> To get the right results when advising or instrumenting code, we could
RS> define (advised-interactive foo) as an alternative to use in wrappers.

RS> (defun foo (y)
RS>   (interactive)
RS>   (was-interactive in-foo)
RS>   ...)

RS> (lambda (x) (advised-interactive in-foo) (message "I am at foo") (foo x))

RS> When the lambda gets called, 'advised-interactive' will bind 'in-foo'
RS> to say whether the call was interactive, and it will suppress the
RS> 'was-interactive' form in 'foo' from binding 'in-foo' (because they
RS> bind the same variable).

If I understand right, an instrumenting code must be aware of the variable
name used internally by a function. That is, when writing defadvice I should
look inside foo in order to figure out that internally it's using in-foo,
and then add (advised-interactive in-foo) in the defadvice code. After this
I will be able to determine whether advised function was called
interactively or not. Is it right? If so then it doesn't seem very good
since coupling with the internal state isn't good.