Re: Advicing the `interactive' form of a command

On Sun, May 3, 2026 at 4:56 PM Roland Winkler <[email protected]> wrote:

> 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.
>

If you put a print statement in your advice, you'll see it does work for
sure.  But I sense that maybe you want to advise 'read-buffer-to-switch
instead.  Give that a try and see if that does what you're looking for.