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: Sun, 20 Oct 2019 08:45:35 +0300 Message-ID: <831rv86kcg.fsf@gnu.org> References: <2058328b-aee5-8cb1-2659-a793e1354517@mit.edu> <835zkndcz4.fsf@gnu.org> <83ftjrbjhm.fsf@gnu.org> <83ftjr9sx4.fsf@gnu.org> <83eezb9s5b.fsf@gnu.org> <83bluf9qgb.fsf@gnu.org> <835zkn9o01.fsf@gnu.org> <83lfti8ovn.fsf@gnu.org> <83d0eu8c80.fsf@gnu.org> <83lfth6p0y.fsf@gnu.org> <7f141905-6be3-2c21-e2af-b5926dd80223@gmail.com> <83a79w7rg6.fsf@gnu.org> <38522c1f-8127-0560-7cc5-7bdce849e650@yandex.ru> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="238051"; mail-complaints-to="usenet@blaine.gmane.org" Cc: cpitclaudel@gmail.com, joaotavora@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 20 07:45:55 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 1iM42L-000zjD-GZ for ged-emacs-devel@m.gmane.org; Sun, 20 Oct 2019 07:45:53 +0200 Original-Received: from localhost ([::1]:50810 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iM42J-0002wN-Ih for ged-emacs-devel@m.gmane.org; Sun, 20 Oct 2019 01:45:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47442) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iM42D-0002w3-Ab for emacs-devel@gnu.org; Sun, 20 Oct 2019 01:45:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iM42C-0004gr-QR; Sun, 20 Oct 2019 01:45:44 -0400 Original-Received: from [176.228.60.248] (port=2931 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iM42C-00019u-9J; Sun, 20 Oct 2019 01:45:44 -0400 In-reply-to: <38522c1f-8127-0560-7cc5-7bdce849e650@yandex.ru> (message from Dmitry Gutov on Sat, 19 Oct 2019 23:41:19 +0300) 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:241246 Archived-At: > Cc: emacs-devel@gnu.org, joaotavora@gmail.com, monnier@iro.umontreal.ca > From: Dmitry Gutov > Date: Sat, 19 Oct 2019 23:41:19 +0300 > > On 19.10.2019 17:14, Eli Zaretskii wrote: > > In the latter case, we > > will have to devise some way of turning on that new mode automatically > > in most cases. > > I don't think that should be a prerequisite. Why not? It would be very unusual and inconvenient for a major mode to require that it be manually turned on to be useful. Do we have any other major mode that needs that? > But even if we wanted that, do we have a lot of other similar files that > are created by the user, as opposed to being auto-generated? In the > latter case we can add a 'mode: elisp-data-mode' to the file while it's > generated with little effort. If we can automatically generate the mode cookie, we can automatically generate any other file-local variable we might need, like 'no-byte-compile: t' or the setting for an Xref backend. I also am not sure that all the features that read these files will be able to DTRT with (either ignore or act upon) file-locals or cookies. At least some of them will probably have to be modified to be able to do that. That's why I said this issue needs to be investigated and the conclusions posted and discussed, before we can design a coherent feature to support such files. Doing that in a hurry, based on a single incident and only on some vague ideas what other aspects of these files may need handling, doesn't sound wise to me, especially as the rest of the issues, whatever they are, cannot be urgent, judging by the lack of complaints.