From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: scratch/command 064f146 1/2: Change command to interactive ... modes Date: Tue, 16 Feb 2021 20:31:01 +0100 Message-ID: <877dn7u7wq.fsf@gnus.org> References: <20210213141225.11309.86562@vcs0.savannah.gnu.org> <87mtw6d480.fsf@gnus.org> <87eehid3k2.fsf@gnus.org> <87r1liblzb.fsf@gnus.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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22173"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: dgutov@yandex.ru, stefankangas@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 16 20:32:19 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 1lC654-0005c0-Qp for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Feb 2021 20:32:18 +0100 Original-Received: from localhost ([::1]:46098 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lC653-0002OL-S2 for ged-emacs-devel@m.gmane-mx.org; Tue, 16 Feb 2021 14:32:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51636) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lC641-0001sq-Oi for emacs-devel@gnu.org; Tue, 16 Feb 2021 14:31:15 -0500 Original-Received: from quimby.gnus.org ([2a01:4f9:2b:f0f::2]:45668) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lC63z-0007EY-0S; Tue, 16 Feb 2021 14:31:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=nZ9m4xMRGFzY6WSIHB+ToQdCe4O9FGRLRZboSk/6TMw=; b=AodZ/mq1eeKhCJ56tfX7MDr1o9 WcsMycQlpCJL5rydFad1bE+TwqgZ4uwTQd7xC6Bk3v+Ee9mYAbQmSNCPh9XoCfopBVQq5WfXrngah 69vts2HDXamuHzrIU1dAp5YV2JCidipOjK81BK355lSLnII2XBHRDSn0m258AsMk8pJs=; Original-Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lC63r-0007tK-Lq; Tue, 16 Feb 2021 20:31:07 +0100 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAJ1BMVEWdYjOlaDascDyq azaaWyueYC91SymZXTBZNh0zIhaIVSysckD////7pIGxAAAAAWJLR0QMgbNRYwAAAAd0SU1FB+UC EBMWGl8edeoAAAFtSURBVDjLnZO/TsMwEMbddmKLZWWACZIxC7afAMnIYqODX6FU2ZCK8gAgRLtl AYkJRjJmzctx/pc4iTPAl9a1a//uLpcvCHkl8F3B5YUXhHCW5RxTDmKZHjOrZQI2OTcAJZznnDtq QtwOBMk5tVOKL9cPhoVsAUGO9f7tK6iKc7dxwh8/dqqhIMfxpT67CYheF+/1+aOPSxChfZLT5x2O EMnuef9Khw1CXLlJia83MQIPp21LfLkjjcqdNRG6R2cACwk1b/s0DuGjtiercVVsXpNp+65pyvJ7 C+s03YaE8cpmQtAr5OKmapsqpYydkK/KuGY4TgnTZtCEDq2M9FI7EgbjLuMaap8pc4ZTCuvgT8rp 3ns3G5DebIaoQEIIKaqDOMBcKf1PTwDD4HQOP3bZIiE1YAVQ5YWKNouo7ZAYScLHEV2U6KaET6aJ bn6+KDQhI4Q0RBtLsZBD/J0Q8l85Fu68imYAolnH3g+MfwEJJMU5uHc/eQAAACV0RVh0ZGF0ZTpj cmVhdGUAMjAyMS0wMi0xNlQxOToyMjoyNiswMDowMNzBFkEAAAAldEVYdGRhdGU6bW9kaWZ5ADIw MjEtMDItMTZUMTk6MjI6MjYrMDA6MDCtnK79AAAAAElFTkSuQmCC X-Now-Playing: John Zorn Masada's _50: 7_: "Hath-Arob" In-Reply-To: <83ft1v97bk.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 16 Feb 2021 20:49:19 +0200") Received-SPF: pass client-ip=2a01:4f9:2b:f0f::2; envelope-from=larsi@gnus.org; helo=quimby.gnus.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:264923 Archived-At: Eli Zaretskii 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