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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: Stefan Kangas <stefankangas@gmail.com>,  dgutov@yandex.ru,
>>   emacs-devel@gnu.org
>> Date: Tue, 16 Feb 2021 23:00:30 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I think these nano-issues, if they are issues at all, don't come close
>> > to justifying incompatible changes.
>> 
>> I think that in the long term, taking care to not make simple things
>> like making a command for a mode too arduous, is important.
>
> I don't think using 'declare' or a plist can be characterized as
> "arduous".
>
>> And again, I don't see what makes extending `interactive' so special
>> here.  We introduce new things in Emacs Lisp all the time when we think
>> that that improves the language.
>
> It's not the extension per se, it's the fact that it causes
> difficulties, as mentioned in this thread.  they may be small
> difficulties, but the alternatives avoid them completely, and aren't
> more complex.  I think using one of the alternatives will leave more
> developers happy, and that in itself is a significant advantage, IMO.

Yes. Among other things, it would accelerate the adoption of the
feature, for instance. If most maintainers of external packages (which
includes Org and C-Mode) refrain from tagging their commands, the value
we get from the filtering diminishes.

As a language designer and implementer myself, I sympathize with Lars'
stance about language evolution but, apart from the controversy it is
facing, it will negatively affect the purpose that intends to serve.
Once the feature is popular enough we can migrate to the `interactive'
form, or even a better solution. This can start a trend about adding
features that depend on metainformation about commands and other
entities and we will benefit from ideas and experience on the coming
months.