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

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Tue, 16 Feb 2021 19:36:52 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I take it that the conclusion to the question I asked ("is there a point
> >> to having the .elc files be compatible when the .el files aren't?") is
> >> "no, there's no point in that".
> >> 
> >> Are we in agreement on that?
> >
> > No, we are not.
> 
> Could you explain what your disagreement is on this point?  That would
> be helpful.

I already explained that.  You didn't agree with my arguments, so I
see no reason to reiterate them.  But that doesn't mean I agree.
Having incompatible byte code is BAD.

> I think that if mode tagging is something that is going to happen on a
> large scale, the mechanism for doing this must be clear, easy and
> maintainable.  Tagging 97% of our commands with
> 
> (defun foo ()
>   (declare (completion foo-mode))
>   (interactive "p"))
> 
> seems like a much worse solution in the "clear and easy" dept than
> 
> (defun foo ()
>   (interactive "p" foo-mode))
> 
> Do you disagree with this?

Yes, I disagree that the former is not clear, easy, and maintainable.
We've been using similar constructs for years.

There was also a suggest to use symbol properties.  that is also
something we use widely in Emacs, including in the new
completion-default-include-p function (and in many other places).

They are all good, clean, maintainable practices which we are using
and will continue to use.  I don't see why 'interactive' is better.
In fact, I could make a case to the contrary: it is already a kind of
magic, as can be clearly seen from its implementation.  Explaining how
it works needs quite a few words.  So it isn't as clear as might
appear at first sight.