all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#66991: Confusion in interactive-form with commands with bare interactive forms.
@ 2023-11-07 16:38 Alan Mackenzie
  2023-11-07 16:49 ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Alan Mackenzie @ 2023-11-07 16:38 UTC (permalink / raw)
  To: 66991

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#66991: Confusion in interactive-form with commands with bare interactive forms.
  2023-11-07 16:38 bug#66991: Confusion in interactive-form with commands with bare interactive forms Alan Mackenzie
@ 2023-11-07 16:49 ` Eli Zaretskii
  2023-11-07 17:10   ` Alan Mackenzie
  2023-11-07 17:32   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2023-11-07 16:49 UTC (permalink / raw)
  To: Alan Mackenzie, Stefan Monnier; +Cc: 66991

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#66991: Confusion in interactive-form with commands with bare interactive forms.
  2023-11-07 16:49 ` Eli Zaretskii
@ 2023-11-07 17:10   ` Alan Mackenzie
  2023-11-07 17:38     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2023-11-07 17:32   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 7+ messages in thread
From: Alan Mackenzie @ 2023-11-07 17:10 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: acm, 66991, Stefan Monnier

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#66991: Confusion in interactive-form with commands with bare interactive forms.
  2023-11-07 16:49 ` Eli Zaretskii
  2023-11-07 17:10   ` Alan Mackenzie
@ 2023-11-07 17:32   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 0 replies; 7+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-07 17:32 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Alan Mackenzie, 66991

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






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#66991: Confusion in interactive-form with commands with bare interactive forms.
  2023-11-07 17:10   ` Alan Mackenzie
@ 2023-11-07 17:38     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2023-11-08  8:56       ` Alan Mackenzie
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-07 17:38 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: Eli Zaretskii, 66991

> 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






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#66991: Confusion in interactive-form with commands with bare interactive forms.
  2023-11-07 17:38     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-11-08  8:56       ` Alan Mackenzie
  2023-11-08 12:29         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 7+ messages in thread
From: Alan Mackenzie @ 2023-11-08  8:56 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, 66991

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#66991: Confusion in interactive-form with commands with bare interactive forms.
  2023-11-08  8:56       ` Alan Mackenzie
@ 2023-11-08 12:29         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-11-08 12:29 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: Eli Zaretskii, 66991

> 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






^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2023-11-08 12:29 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-11-07 16:38 bug#66991: Confusion in interactive-form with commands with bare interactive forms Alan Mackenzie
2023-11-07 16:49 ` Eli Zaretskii
2023-11-07 17:10   ` Alan Mackenzie
2023-11-07 17:38     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-08  8:56       ` Alan Mackenzie
2023-11-08 12:29         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-07 17:32   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.