emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: scratch/command 064f146 1/2: Change command to interactive ... modes


From: Alan Mackenzie
Subject: Re: scratch/command 064f146 1/2: Change command to interactive ... modes
Date: Sun, 14 Feb 2021 16:58:13 +0000

On Sun, Feb 14, 2021 at 10:03:57 -0600, Stefan Kangas wrote:
> Stefan Kangas <stefankangas@gmail.com> writes:

> > Dmitry Gutov <dgutov@yandex.ru> writes:

> >> If it's not backward-compatible at all, however, I wouldn't feel
> >> comfortable with using it in my packages for years to come.

> > Could we write a macro `future-interactive' that will expand to the
> > correct thing depending on the version of Emacs?  We could put something
> > like that in GNU ELPA.  (I'm not sure the order in which things are
> > expanded, so this might not work.)

> This seems to work as expected on both master and Emacs 27:

> (defmacro future-interactive (arg-descriptor &rest modes)
>   (if (< emacs-major-version 28)
>       `(interactive ,arg-descriptor)
>     `(interactive ,arg-descriptor ,@(mapcar #'eval modes))))

It won't work in Emacsen before Emacs 28, because it doesn't exist on
those systems.  This idea would mean having to distribute the macro with
every package, with all the evils that would entail.

> (defun foo (arg)
>   (future-interactive "P" 'fundamental-mode)
>   (message "P was %s" arg))

Please, can't we just halt all this and take stock?  `interactive'
specifies how to call a lisp function interactively.  This new stuff
being put it has nothing to do with the interactive call.  It will foul
things up horribly.

Why can't this new feature be implemented without introducing
incompatibilities?

What am I missing?

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]