From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: scratch/command 064f146 1/2: Change command to interactive ... modes Date: Wed, 17 Feb 2021 22:12:24 +0200 Message-ID: <83sg5u5u8n.fsf@gnu.org> 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> <87y2fm1ohp.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22473"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dgutov@yandex.ru, stefankangas@gmail.com, emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 17 21:13:16 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 1lCTCE-0005jb-R7 for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 21:13:14 +0100 Original-Received: from localhost ([::1]:60370 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCTCD-0000Sl-RK for ged-emacs-devel@m.gmane-mx.org; Wed, 17 Feb 2021 15:13:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58504) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lCTBH-0007nY-UP for emacs-devel@gnu.org; Wed, 17 Feb 2021 15:12:15 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54359) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lCTBH-0004Ph-I2; Wed, 17 Feb 2021 15:12:15 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4800 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lCTBF-0005Zg-LJ; Wed, 17 Feb 2021 15:12:14 -0500 In-Reply-To: <87y2fm1ohp.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 17 Feb 2021 20:30:10 +0100) 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:265075 Archived-At: > From: Lars Ingebrigtsen > Date: Wed, 17 Feb 2021 20:30:10 +0100 > Cc: emacs-devel@gnu.org, stefankangas@gmail.com, dgutov@yandex.ru > > Eli Zaretskii writes: > > >> 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". > > I think it is. We'd be demanding that people learn about obscure things > like `declare' just to write a little mode. That's not good language > design. Neither 'declare' nor 'plist' are obscure. We use them all over the place. So we will have to agree to disagree about this. > > 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. > > The difficulties are minuscule. We will have to agree to disagree about this as well. And please note that I'm not the only one who disagrees with you and prefers to use one of the alternatives. > If somebody wants to write code that backwards-compatible, then use the > compat library or use `declare'. I don't see why that should stop us > from making the Emacs Lisp language better, and use the best language > construction in our in-tree code. Using more than one construct for this is worse than using any one of the possible solutions. And I don't think the issue here is improving the language, the issue is how to implement a feature with minimum adverse effects. It's about pragmatics, not about language development.