From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: scratch/command 064f146 1/2: Change command to interactive ... modes Date: Wed, 17 Feb 2021 20:01:18 +0100 Message-ID: <87o8gia58h.fsf@telefonica.net> References: <20210213141225.11309.86562@vcs0.savannah.gnu.org> <83y2fq9f0v.fsf@gnu.org> <87k0r8xl7y.fsf@gnus.org> <834kic9g0a.fsf@gnu.org> <8735xwvusc.fsf@gnus.org> <83v9as7xns.fsf@gnu.org> <87pn10ueld.fsf@gnus.org> <83r1lf9apm.fsf@gnu.org> <87a6s3vrnd.fsf@gnus.org> <83o8gj9a8o.fsf@gnu.org> <871rdfvq86.fsf@gnus.org> <83h7mb98g8.fsf@gnu.org> <87o8gjuaez.fsf@gnus.org> <83ft1v97bk.fsf@gnu.org> <877dn7u7wq.fsf@gnus.org> <835z2r94zw.fsf@gnu.org> <831rdf91r1.fsf@gnu.org> <87ft1vsmf5.fsf@gnus.org> <83v9aq7m9a.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28911"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: emacs-devel@gnu.org Cancel-Lock: sha1:6sErXMd+SawWETDjTXHBoPozWsA= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 17 20:03:25 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lCS6e-0007Pt-EB for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 20:03:24 +0100 Original-Received: from localhost ([::1]:58874 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCS6d-0001WC-DW for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 14:03:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41524) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCS4p-0000Sy-1f for emacs-devel@gnu.org; Wed, 17 Feb 2021 14:01:31 -0500 Original-Received: from ciao.gmane.io ([116.202.254.214]:60406) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCS4m-0001SK-Dm for emacs-devel@gnu.org; Wed, 17 Feb 2021 14:01:29 -0500 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lCS4i-0005Oj-Dv for emacs-devel@gnu.org; Wed, 17 Feb 2021 20:01:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:265049 Archived-At: Eli Zaretskii writes: >> From: Lars Ingebrigtsen >> Cc: Stefan Kangas , dgutov@yandex.ru, >> emacs-devel@gnu.org >> Date: Tue, 16 Feb 2021 23:00:30 +0100 >> >> Eli Zaretskii 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.