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: Fri, 18 Oct 2019 11:00:12 +0300 Message-ID: <83lfti8ovn.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> <835zkn9o01.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="30390"; mail-complaints-to="usenet@blaine.gmane.org" Cc: cpitclaudel@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 18 10:10:20 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 1iLNL0-0007lF-CL for ged-emacs-devel@m.gmane.org; Fri, 18 Oct 2019 10:10:18 +0200 Original-Received: from localhost ([::1]:36298 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLNKy-0003Rs-W4 for ged-emacs-devel@m.gmane.org; Fri, 18 Oct 2019 04:10:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34319) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLNBU-00033H-4m for emacs-devel@gnu.org; Fri, 18 Oct 2019 04:00:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:56329) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iLNBT-0005zA-KZ; Fri, 18 Oct 2019 04:00:27 -0400 Original-Received: from [176.228.60.248] (port=1397 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iLNBS-0000JS-LN; Fri, 18 Oct 2019 04:00:27 -0400 In-reply-to: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Thu, 17 Oct 2019 22:35:33 +0100) 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:241190 Archived-At: > From: João Távora > Date: Thu, 17 Oct 2019 22:35:33 +0100 > Cc: Stefan Monnier , > Clément Pit-Claudel , > emacs-devel@gnu.org > > Which class of problems is that? I see only one problem that was > clearly identified and described: the .dir-locals.el file, and the > problem is that Flymake erroneously reports problems in that file. > > The class can informally be described by "functionality not applicable and thus harmful to the manipulation of > non-code lisp data files." We already handle this in several places by explicitly exempting .dir-locals.el from some operations that make no sense with it. Why ios this problem different? > What misdesign is that? > > A failure to correctly model the differences between lisp code and > lisp data. There is no difference, not in general, not in Lisp. > I don't think I understand what you are saying here. Can we step back > a notch and start by describing the problem in more detail? What > diagnostics does Flymake produce in the case of .dir-locals.el, and > why does it produce that diagnostics? > > I haven't checked, but if I had to guess, I would say it tries to invoke the byte-compiler on the file, which > doesn't make any sense, as you know. As a result, bogus diagnostics are produced. The byte compiler already knows to ignore .dir-locals.el, at least in one of its commands. If this is the only problem, maybe we need to add that exemption in a couple of more places. So I think we do need a detailed description of the problem, because otherwise I think this discussion might be based on different perceptions of what the problem is, and thus we have no common ground for assessing the proposed solutions. > No, because this new mode is defined in a place that is not Flymake. > So when some change is done in Flymake that affects that mode, someone > needs to remember to update an unrelated mode in an unrelated source > file. > > No. Simply no. We might be miscommunicating, but when a change happens in Flymake, the new mode > proposed by Stefan need not be changed. At all. I don't think I agree. If Flymake is modified to do some meaningful checks of .dir-locals.el, we may wish to remove this special major mode as not needed anymore. Anyway, I think this discussion needs to have a detailed description of the problem, before we can continue talking about solutions.