From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Add a separate mode for .dir-locals.el Date: Sat, 19 Oct 2019 13:00:19 +0300 Message-ID: <83k1916ong.fsf@gnu.org> References: <2058328b-aee5-8cb1-2659-a793e1354517@mit.edu> <87wod4m7sr.fsf@gnus.org> <835zkndcz4.fsf@gnu.org> <83ftjrbjhm.fsf@gnu.org> <83ftjr9sx4.fsf@gnu.org> <83eezb9s5b.fsf@gnu.org> <83bluf9qgb.fsf@gnu.org> <831rvb9m9d.fsf@gnu.org> <83mudy8p99.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="68167"; mail-complaints-to="usenet@blaine.gmane.org" Cc: cpitclaudel@gmail.com, joaotavora@gmail.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 19 12:00:57 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iLlXd-000HaK-LN for ged-emacs-devel@m.gmane.org; Sat, 19 Oct 2019 12:00:57 +0200 Original-Received: from localhost ([::1]:52272 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLlXc-0003vS-Ed for ged-emacs-devel@m.gmane.org; Sat, 19 Oct 2019 06:00:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48642) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLlXN-0003vC-Oo for emacs-devel@gnu.org; Sat, 19 Oct 2019 06:00:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iLlXN-00058m-Fd; Sat, 19 Oct 2019 06:00:41 -0400 Original-Received: from [176.228.60.248] (port=1911 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iLlXE-0001oF-Rb; Sat, 19 Oct 2019 06:00:37 -0400 In-reply-to: (message from Stefan Monnier on Fri, 18 Oct 2019 09:11:19 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:241220 Archived-At: > From: Stefan Monnier > Date: Fri, 18 Oct 2019 09:11:19 -0400 > Cc: cpitclaudel@gmail.com, joaotavora@gmail.com, emacs-devel@gnu.org > > >> ... other things we may want to fix such as the M-C-x binding which > >> makes no sense in .dir-locals.el, or the presence of "Byte-compile > >> this file" in the menu, ... > > > > The former might make sense, because .dir-locals.el can include 'eval' > > forms, right? > > No, because those forms won't start in column 0, so C-x C-e might work, > but C-M-x won't. But 'eval' forms could also include a defun, could they not? > > If we care about the latter, it can be handled by being > > sensitive to 'no-byte-compile: t' instead. > > You really want to have to add `no-byte-compile: t` to every > .dir-locals.el instead of adding an auto-mode-alist rule? How is it different from adding 'mode: elisp-data' to every relevant file? You did say there were files whose names are not .dir-locals.el, right? > > Or even compare with the file name, as bytecomp.el already does, as do > > other places. > > Yes, we can come up with all kinds of hacks, of course. You can call those "hacks", but we've been doing them for quite some time, and evidently didn't consider them to be such bad hacks. Suddenly one more of them makes them unbearable? > Not sure why you'd want to do that instead of using the clean&simple > approach of a separate major mode so you can rely on standard > mechanisms like auto-mode-alist. Because I don't consider it clean. > This then lets us solve the original problem by adding a single line > to auto-mode-alist which can be trivially shown to only affect those > files that happen to match the regexp we choose to use there. It isn't a single line, see above. > Creating a major mode is cheap and easy. No need to be afraid. Even if > it inserts itself inside a pre-existing part of the hierarchy as is the > case here. Creating a major mode for this issue is like shooting sparrows with cannons. Why not extend emacs-lisp-mode to DTRT with data-that-doesn't-make-sense-as-code instead?