From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Smarter M-x that filters on major-mode Date: Sun, 14 Feb 2021 15:03:53 +0000 Message-ID: References: <87pn16mehu.fsf@gnus.jao.io> <87o8gpvdfd.fsf@gnus.org> <87a6s9mf87.fsf@gnus.jao.io> <87o8goryuj.fsf@gnus.org> <87y2fqepza.fsf_-_@gnus.org> <87pn12u3x8.fsf@tcd.ie> <87h7meenj0.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15136"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "Basil L. Contovounesios" , emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Feb 14 16:04:33 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 1lBIwr-0003oC-4F for ged-emacs-devel@m.gmane-mx.org; Sun, 14 Feb 2021 16:04:33 +0100 Original-Received: from localhost ([::1]:50628 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lBIwq-0001eI-6f for ged-emacs-devel@m.gmane-mx.org; Sun, 14 Feb 2021 10:04:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34854) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lBIwJ-0001CX-7i for emacs-devel@gnu.org; Sun, 14 Feb 2021 10:03:59 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:53757 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lBIwG-0005aH-Pr for emacs-devel@gnu.org; Sun, 14 Feb 2021 10:03:58 -0500 Original-Received: (qmail 14478 invoked by uid 3782); 14 Feb 2021 15:03:54 -0000 Original-Received: from acm.muc.de (p2e5d5f6c.dip0.t-ipconnect.de [46.93.95.108]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 14 Feb 2021 16:03:54 +0100 Original-Received: (qmail 6111 invoked by uid 1000); 14 Feb 2021 15:03:53 -0000 Content-Disposition: inline In-Reply-To: <87h7meenj0.fsf@gnus.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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:264705 Archived-At: Hello, Lars. On Sun, Feb 14, 2021 at 15:23:31 +0100, Lars Ingebrigtsen wrote: > "Basil L. Contovounesios" writes: > > I'm curious, though: if (interactive ARG MODES...) is neither forward > > nor backward compatible, > I'm not sure what you mean by "forward compatible" here... Emacs 29 > should be able to use it just fine? > > and is equivalent to (declare (modes MODES...)), then why not allow > > only the latter syntax? Or am I missing something? > Since approx. 97% of commands will eventually have this markup, that > means that 97% of commands will start with > (declare (modes foo-mode)) > (interactive "p") > and that seems like too much line noise. We don't have to make Emacs > Lisp into Java. Please stop. Please just stop and rethink. Filtering out stuff from an M-x search is a minor feature. You're proposing turning the structures of Emacs upside down in implementing it. This is disproportionate, and will bring unforeseen problems with it. `interactive' currently does one thing and does it well - it says how to call a function interactively. You're advocating adding unrelated stuff into `interactive'. That is ugly, horribly ugly. You're proposing making the .elc format backward incompatible, all for what? For some minor feature to do with M-x. A feature which not everybody wants (I certainly don't), and not everybody will use. You're proposing encouraging (or even "encouraging") people to make their libraries backward incompatible, something which will meet considerable resistance. (Dmitry, I think, has already expressed an unwillingness to make such changes to his packages.) Also the DEFUN macro will need modifying. This won't be pretty. Please just leave `interactive' alone. Please just leave the .elc format alone. There are other ways to do what this proposal is proposing (I've forgotten exactly what this is) - why not just add a property called `minor-modes' to the functions' symbols? Or something like that? > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no -- Alan Mackenzie (Nuremberg, Germany).