Re: Advicing the `interactive' form of a command

On Sun, May 03 2026, Stéphane Marks wrote:
> Advising functions, interactive or not, works under lexical scope. 
> Be sure you're running your tests in a buffer with lexical binding. 
> Run the command elisp-enable-lexical-binding in your test buffer if
> you're not sure.
>
> The example you gave definitely works for my use cases.  

I am not sure I understand your suggestion.  When I load the test case
into "emacs- Q" (emacs 30.1) the adviced `switch-to-buffer' recognizes
the outer

 (setq confirm-nonexistent-file-or-buffer nil)

but it ignores the let-binding of `confirm-nonexistent-file-or-buffer'
in the advice.  This happens when I load the test case as uncompiled
code or byte-compiled (starting from a file with a 
  ;;;  -*- lexical-binding: t -*-
in the first line).

Or are you saying that the buffer where I run the adviced `switch-to-buffer'
should have lexical binding enabled?  Running the command
`elisp-enable-lexical-binding' in the *scratch* buffer of "emacs -Q"
gives me "lexical-binding already enabled!".
In any case, `switch-to-buffer' is a command that should work the same in
any buffer.

> The "interactivity" of a function is tested by the command loop for
> the presence of the 'interactive-form property on the function symbol.
> You can see that property by invoking (interactive-form
> 'switch-to-buffer).  It does not impact the advice chain that I've
> seen.

I am sorry, again I am not sure I understand.  I would like to put an
advice around the interactive spec of `switch-to-buffer' which is
different from putting advice around the body of this command.  The
latter assumes that the args processed in the body are already known;
they are passed to the around advice which can do anything with them.
The advice around the interactive spec should affect how this command
reads its args interactively.  Unless the code for advice looks deep
into the around advice (with a crystal ball?) I'd find it difficult to
handle these rather different use cases under the umbrella of the same
:around arg for `advice-add'.

Interestingly, it is possible to *replace* the interactive spec for
switch-to-buffer if the around FUNCTION passed to `advice-add' brings
along its own interactive spec (a behavior that isn't documented in the
elisp manual).  This is my current workaround.  Certainly, this makes it
explicit that the user doesn't want to use the original interactive
spec.  However, replacing the original interactive spec is a more
radical step.  It isn't ideal for a command like switch-to-buffer where
the original interactive spec is more sophisticated with various bells
and whistles.