bug#66991: Confusion in interactive-form with commands with bare interactive forms.

bug#66991: Confusion in interactive-form with commands with bare interactive forms.

[Alan Mackenzie]

Hello, Emacs

Consider commands with no arguments, and do interactive-form on them:

(interactive-form 'x-print-frames-dialog) => (interactive "") # a primitive

(interactive-form 'universal-argument) => (interactive nil) # a native
                                                      compiled command.
The result is the same from a byte compiled command.

Write (defun foo () (interactive)) in *scratch*, and C-M-x to evaluate
it:
(interactive-form 'foo) => (interactive).

That's three different inconsistent ways of expressing "(interactive".
This is a bug.  For consistency's sake, two of them must be incorrect.

I believe the correct one is the last of these, "(interactive)" which is
after all, what appears in the Lisp sources.  The fix should be
relatively simple, in Finteractive_form in src/data.c

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#66991: Confusion in interactive-form with commands with bare interactive forms.

[Eli Zaretskii]

> Date: Tue, 7 Nov 2023 16:38:51 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> Consider commands with no arguments, and do interactive-form on them:
> 
> (interactive-form 'x-print-frames-dialog) => (interactive "") # a primitive
> 
> (interactive-form 'universal-argument) => (interactive nil) # a native
>                                                       compiled command.
> The result is the same from a byte compiled command.
> 
> Write (defun foo () (interactive)) in *scratch*, and C-M-x to evaluate
> it:
> (interactive-form 'foo) => (interactive).
> 
> That's three different inconsistent ways of expressing "(interactive".
> This is a bug.  For consistency's sake, two of them must be incorrect.

Why?  Please explain in more positive terms why two out of three must
be bugs, not just in some abstract philosophical terms.

> I believe the correct one is the last of these, "(interactive)" which is
> after all, what appears in the Lisp sources.  The fix should be
> relatively simple, in Finteractive_form in src/data.c

Please wait with implementing a fix until we discuss the issue and
decide whether and how it should be fixed.

Adding Stefan to the discussion.

bug#66991: Confusion in interactive-form with commands with bare interactive forms.

[Alan Mackenzie]

Hello, Eli.

On Tue, Nov 07, 2023 at 18:49:38 +0200, Eli Zaretskii wrote:
> > Date: Tue, 7 Nov 2023 16:38:51 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > Consider commands with no arguments, and do interactive-form on them:

> > (interactive-form 'x-print-frames-dialog) => (interactive "") # a primitive

> > (interactive-form 'universal-argument) => (interactive nil) # a native
> >                                                       compiled command.
> > The result is the same from a byte compiled command.

> > Write (defun foo () (interactive)) in *scratch*, and C-M-x to evaluate
> > it:
> > (interactive-form 'foo) => (interactive).

> > That's three different inconsistent ways of expressing "(interactive".
> > This is a bug.  For consistency's sake, two of them must be incorrect.

> Why?  Please explain in more positive terms why two out of three must
> be bugs, not just in some abstract philosophical terms.

I get a failure in /test/src/comp-tests.log in test
comp-tests-interactive-form, where the test is expecting

    (interactive)

but the result of running the test innards is

    (interactive nil)

..  I don't understand why I'm only seeing this test failure now.  Maybe
it's a new test.

Also, I think consistency in this sort of thing is a Good Thing.

> > I believe the correct one is the last of these, "(interactive)" which is
> > after all, what appears in the Lisp sources.  The fix should be
> > relatively simple, in Finteractive_form in src/data.c

> Please wait with implementing a fix until we discuss the issue and
> decide whether and how it should be fixed.

OK.  :-)  But I think fixing data.c will be easier and cleaner than
fixing all the tests which might test it.

> Adding Stefan to the discussion.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#66991: Confusion in interactive-form with commands with bare interactive forms.

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> I get a failure in /test/src/comp-tests.log in test
> comp-tests-interactive-form, where the test is expecting
>
>     (interactive)
>
> but the result of running the test innards is
>
>     (interactive nil)

I'd argue the test should accept either form.

> ..  I don't understand why I'm only seeing this test failure now.

Indeed, it's odd.

> Maybe it's a new test.

`git log test/lisp/emacs-lisp/comp-tests.el` suggests there's been no
activity there of late.

> OK.  :-)  But I think fixing data.c will be easier and cleaner than
> fixing all the tests which might test it.

I wouldn't call it a fix because I don't think the current behavior is
broken, but I see no problem with `interactive-form` replacing
`(interactive)` for `(interactive nil)` when it can do so cheaply.
It may break other (broken) tests, of course.


        Stefan

bug#66991: Confusion in interactive-form with commands with bare interactive forms.

[Alan Mackenzie]

Hello, Stefan.

On Tue, Nov 07, 2023 at 12:38:34 -0500, Stefan Monnier wrote:
> > I get a failure in /test/src/comp-tests.log in test
> > comp-tests-interactive-form, where the test is expecting

> >     (interactive)

> > but the result of running the test innards is

> >     (interactive nil)

> I'd argue the test should accept either form.

> > ..  I don't understand why I'm only seeing this test failure now.

> Indeed, it's odd.

> > Maybe it's a new test.

> `git log test/lisp/emacs-lisp/comp-tests.el` suggests there's been no
> activity there of late.

> > OK.  :-)  But I think fixing data.c will be easier and cleaner than
> > fixing all the tests which might test it.

> I wouldn't call it a fix because I don't think the current behavior is
> broken, but I see no problem with `interactive-form` replacing
> `(interactive)` for `(interactive nil)` when it can do so cheaply.
> It may break other (broken) tests, of course.

What about replacing (interactive "") with (interactive) too, and
documenting this?

The doc string says that "Return the interactive form of CMD, or nil
....".  But you seem to be arguing that there is no unique _THE_
interactive form.  Just three possibilities for _AN_ interactive form.
The doc string doesn't make this clear, and needs amending anyway.

To fix only the doc string rather than the code too, would double the doc
string's size.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#66991: Confusion in interactive-form with commands with bare interactive forms.

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> What about replacing (interactive "") with (interactive) too, and
> documenting this?

Why?

> The doc string says that "Return the interactive form of CMD, or nil
> ....".  But you seem to be arguing that there is no unique _THE_
> interactive form.

The interactive form is either a string or code.  When it's a string,
I expect you get the one and only `(interactive THE-STRING)`, but when
it's not a string ... well ... by definition the compiler changes the
representation of code so it's completely expected that you won't get
necessarily quite the same code (as long as its execution is equivalent).

> The doc string doesn't make this clear, and needs amending anyway.

Maybe, but I don't understand why you think it's necessary.

> To fix only the doc string rather than the code too, would double the
> doc string's size.

And this suggests we should also document `symbol-function` to say that
it may not return something identical to what you wrote in the
source code.


        Stefan

bug#66991: Confusion in interactive-form with commands with bare interactive forms.

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> (interactive-form 'x-print-frames-dialog) => (interactive "") # a primitive
>> 
>> (interactive-form 'universal-argument) => (interactive nil) # a native
>>                                                       compiled command.

Both seem acceptable: the form can be either a string interpreted
internally by `call-interactively` or an expression whose value will
be the list of arguments.  It so happens that the interpretation of ""
results in an empty list of args, just like nil.  There might be
commands out there which use alternative ways to express such an empty
list, such as

    (interactive 'nil)

[ Presumably as a result of macro expansion of something like
  ...(interactive ',args)... ]

or

    (interactive (< 4 3))

[ Presumably the result of a prank or some such :-)  ]

Where/why do you need the representation to be more ... canonical?

>> The result is the same from a byte compiled command.
>>
>> Write (defun foo () (interactive)) in *scratch*, and C-M-x to evaluate
>> it:
>> (interactive-form 'foo) => (interactive).

For non-compiled functions, we just use `assq` on the body.
It's arguably not 100% correct, but it gets the job done cheaply.
It usually doesn't matter because `cadr` on this result is still nil.

>> That's three different inconsistent ways of expressing "(interactive".

Different, yes, but I don't see what's inconsistent about it, except
maybe for the fact that `interactive-form` can change from
`(interactive)` for an interpreted function to
`(interactive nil)` for the same function once it's byte-compiled, but
note that `(interactive EXP)` will generally change once byte-compiled
because EXP gets byte-compiled as well, so you generally can't presume
that `interactive-form` returns the exact same data-structure before and
after byte-compilation: the two should be "equivalent" but not
necessarily identical.


        Stefan