From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Add a separate mode for .dir-locals.el Date: Thu, 17 Oct 2019 22:35:33 +0100 Message-ID: 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: multipart/alternative; boundary="00000000000005ad7a05952200cc" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="185669"; mail-complaints-to="usenet@blaine.gmane.org" Cc: =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= , Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 17 23:36:36 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 1iLDRi-000mB7-SL for ged-emacs-devel@m.gmane.org; Thu, 17 Oct 2019 23:36:35 +0200 Original-Received: from localhost ([::1]:60572 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLDRh-0001XX-OL for ged-emacs-devel@m.gmane.org; Thu, 17 Oct 2019 17:36:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59221) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLDR0-0001XM-2W for emacs-devel@gnu.org; Thu, 17 Oct 2019 17:35:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iLDQy-0005UL-LC for emacs-devel@gnu.org; Thu, 17 Oct 2019 17:35:49 -0400 Original-Received: from mail-io1-xd36.google.com ([2607:f8b0:4864:20::d36]:43587) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iLDQw-0005Sc-Oo; Thu, 17 Oct 2019 17:35:46 -0400 Original-Received: by mail-io1-xd36.google.com with SMTP id v2so4893279iob.10; Thu, 17 Oct 2019 14:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/Cs1iKfJrLlolMEm+uSbWiG6KOrLkiVlYOYG2mS9egM=; b=CYwWXiHJz0lN9tf8SPDbjbnBQvgoYZLhVWKLi1qDydwd1B7YzlWg8zLMF7mrlPVeFV +7oyFk8ZDrcchcSWK6nc+h+RBkyj60M3GGXA8RgRWRIuBWsN89qTihGWHsQ3vR4Fjs3K +vo+I90NPuHBMx9qBb9cfUiJxI3Si9BMj1y3SOFgFUafEIgP0Q5VoND1TiIfnrW4VUfc H6L4bwB2Rjr84L89y2jaYUEyiM7T4cJdFar2Gs28artv9mZqpahxuZv5CplWX1DRpZ8B 2lDYMyfabJVD7m4+JRoO7c6Vbrsa9Qz7jFiIqRS3Q05LjzBVRV4yuwnAoCbaMzsmQ1Gw cFZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/Cs1iKfJrLlolMEm+uSbWiG6KOrLkiVlYOYG2mS9egM=; b=iZ5XmU7zPE7HGBpWam5Q/lz57rI8po3u8+3EjkDVvwPWjd1b/v5P2SASgw9HP267YY pPjACm/3DLZFVEJeLrT3QFz51ksP2zRVlNNW38Rd8xfcXlfTh50JLoGsvKkaVV1n+J2/ vWggKK4VWDHColDIkTarcDqS73oE6t4c44RF4KvTevyDMl9hwoUZQlemyhz2Z5tb6Qxk oXq25tbtt9AuH72aBsx5aE6VHAtQoYDIQB8Wy9h0xRcQG71MXs1NCA2VenRHMTwBDn4t +pqBJ+Zz60HmS1w6tFjhomdwf8o8rE+msZmKbWrObwaZFjraL6kiblS0VEA599wUg5hB +6lA== X-Gm-Message-State: APjAAAXfy+B4NZrCowJHJSYU3ICKhEf8HXpR73M5mPTHZCOVkGCwixg+ PuF7BJbg5qa7RALXr1swU7Sm6DGcGYxXWN9Et/s48w== X-Google-Smtp-Source: APXvYqwhZdwG4Z2LGMqvOqyo9xJxElgxvkhsxdWj4/Ry42/3TZzvghFDYCHlIFvlN0OE4KSmZvLjcsD9Rl+ISuZLDl0= X-Received: by 2002:a5d:9dd6:: with SMTP id 22mr4734406ioo.97.1571348145350; Thu, 17 Oct 2019 14:35:45 -0700 (PDT) In-Reply-To: <835zkn9o01.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d36 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:241180 Archived-At: --00000000000005ad7a05952200cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 17, 2019, 20:21 Eli Zaretskii wrote: > > 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." What misdesign is that? > A failure to correctly model the differences between lisp code and lisp data. It's not a giant flaw, tho: inheritance is available and this is a textbook example of where it should used. > 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? > 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. 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. Stefan's patch doesn't mention anything related to Flymake, so I don't > understand what you are trying to say here. > Exactly. Stefan's patch doesn't change anything related to Flymake and indeed solves the problem (or as i said, the class of problems where this one related to Flymake happens to be included). And that is why it is very good and you should take it! Indeed it answers your very legitimate concerns about maintenance. What drawbacks do you see in the other solution? I see only > advantages. > The least bad one has code duplication, is less maintainable is specific to Flymake. You are basically saying that emacs-lisp-mode should do for these > files. > No. I'm saying that it does a superset of what it should do. And that the surplus is harmful. You can see exactly what that surplus is: it's whatever is left in emacs-lisp-mode in Stefan's patch. Jo=C3=A3o > --00000000000005ad7a05952200cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 17, 2019, 20:21 Eli Zaretskii <eliz@gnu.org> wrote:

Which class of problems is that?=C2=A0 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."

What misdesign is that?

<= /div>
A failure to correctly model the differences between= lisp code and lisp data. It's not a giant flaw, tho: inheritance is av= ailable and this is a textbook example of where it should used.

> But others have suggested more situations.=C2=A0 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.=C2=A0 Can we step = back
a notch and start by describing the problem in more detail?=C2=A0 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 t= o guess, I would say it tries to invoke the byte-compiler on the file, whic= h doesn't make any sense, as you know. As a result, bogus diagnostics a= re produced.

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.

Stefan's patch doesn't mention anything related to Flymake, so I do= n't
understand what you are trying to say here.

Exactl= y. Stefan's patch doesn't change anything related to Flymake and in= deed solves the problem (or as i said, the class of problems where this one= related to Flymake happens to be included). And that is why it is very goo= d and you should take it! Indeed it answers your very legitimate concerns a= bout maintenance.

What drawbacks do you see in the other solution?=C2=A0 I see only
advantages.

The least bad one=C2=A0 has code duplication, is less maintainab= le is specific to Flymake.

You are basically saying that emacs-lisp-mode should do for these
files.

No. I'm saying that it does a superset of what it should do. And = that the surplus is harmful. You can see exactly what that surplus is: it&#= 39;s whatever is left in emacs-lisp-mode in Stefan's patch.

Jo=C3=A3o
--00000000000005ad7a05952200cc--