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: Thu, 17 Oct 2019 22:21:34 +0300 Message-ID: <835zkn9o01.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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="155445"; mail-complaints-to="usenet@blaine.gmane.org" Cc: cpitclaudel@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 17 21:22:35 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 1iLBM3-000eKv-Hm for ged-emacs-devel@m.gmane.org; Thu, 17 Oct 2019 21:22:35 +0200 Original-Received: from localhost ([::1]:57706 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLBM1-0007L7-Um for ged-emacs-devel@m.gmane.org; Thu, 17 Oct 2019 15:22:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39223) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLBLM-0007KF-Pc for emacs-devel@gnu.org; Thu, 17 Oct 2019 15:21:54 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iLBLM-0007yF-ET; Thu, 17 Oct 2019 15:21:52 -0400 Original-Received: from [176.228.60.248] (port=3035 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iLBLL-0006D7-Up; Thu, 17 Oct 2019 15:21:52 -0400 In-reply-to: (message from =?iso-8859-1?Q?Jo?= =?iso-8859-1?Q?=E3o_T=E1vora?= on Thu, 17 Oct 2019 20:00:38 +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:241169 Archived-At: > From: João Távora > Cc: monnier@iro.umontreal.ca, cpitclaudel@gmail.com, emacs-devel@gnu.org > Date: Thu, 17 Oct 2019 20:00:38 +0100 > > I'm truly very sorry you interpreted it this way, and for the record I > think you're a great co-maintainer. I didn't mean quotes to be meant in > a way that belittled your statement: you'll just have to believe me, I > meant them as in I was quoting you. And I know "gross" has a precise > technical meaning in this list (I've seen you use it more often). OK. > > "Gross" means that it solves the problem not where it is caused, and > > thus makes the maintenance harder by spreading information far from > > where it should be. Who will remember that we introduced this mode > > to fix that particular problem, > > No need: we introduce this change to fix a class of problems, not a > particular one. 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. What other problems are clearly described like this one? > The particular situation regarding the flymake-diagnostic-functions > local happens to fit in that class. It's a symptom of misdesign, > not a cause. What misdesign is that? > But others have suggested more situations. I don't think the same > xref-backend-functions apply to .dir-locals or ~/.emacs.d/recentf > files for example. 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? > > and who will know that it may need to be updated or removed, depending > > on the future development of Flymake? No one will remember. > > I don't understand: the exact same maintenance effort motivated by a > that hypothetical change to Flymake will be exerted whether we do this > change or don't. 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. > That's easy to see from Stefan's patch: the same > number of mentions (2) to flymake-diagnostic-functions persist in the > exact same places where they did before, which is the major mode > function emacs-lisp-mode. There is no duplication, inheritance is > linear and models "is a". Stefan's patch doesn't mention anything related to Flymake, so I don't understand what you are trying to say here. > Other than that, I really don't see drawbacks to this. And, to state > the obvious, since I see drawbacks to the other solutions, I am for this > one. What drawbacks do you see in the other solution? I see only advantages. > > I suggested to look at the other similar files and try to describe > > their common traits as a means to arrive at the decision whether we > > might need some variant of ELisp mode for such files. > > One common trait is being lisp data that is READable. I don't think I see how this is relevant to major modes. Emacs major modes don't care whether the text is readable by some interpreter or not (and any Emacs Lisp is also readable, btw). Emacs major modes care about syntax. > Another common trait is being structured data, so syntax is the > same, sexp navigation automatically applies, as does > electric-pair-mode, etc. Basically, whatever is in > lisp-mode-variables, as someone pointed-out. I think the proposed > name, emacs-lisp-data-mode, sums it up well. You are basically saying that emacs-lisp-mode should do for these files. Which is what we use now.