GNU bug report logs - #66991
Confusion in interactive-form with commands with bare interactive forms.

Previous Next

Full log

Message #11 received at 66991 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, 66991 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#66991: Confusion in interactive-form with commands with bare
 interactive forms.
Date: Tue, 7 Nov 2023 17:10:02 +0000

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.