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

[Lars Ingebrigtsen <larsi@gnus.org>]

Eli Zaretskii <eliz@gnu.org> writes:

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

OK, I must have missed the arguments.  Beyond it being bad, in a general
way, for some reason or other.

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

That's not quite a response to what I asked: Which one of those syntaxes
are clearer and easier?  (To read and to write.)

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

I think it's clear that the new interactive spec leads to commands that
are easier to read and write than if (virtually all) commands need a
second (pretty obscure) incantation -- interactive/declare then works in
concert, and you have to understand both.

The question is then: Is this clarity worth it to introduce a
non-backwards compatible syntax in Emacs Lisp?  My answer is, of course,
"yes", but I can see that there might be disagreement on that point.  My
answer, to restate it yet again, is that Emacs Lisp has never shied away
from introducing new macros, functions and special forms if we think
that's the best long-term language solution.

Code meant for older Emacs versions then can't use the new syntax, but
that's not special for `interactive' -- it's the same with any new form.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no