From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Newsgroups: gmane.emacs.devel Subject: Re: Add a separate mode for .dir-locals.el Date: Fri, 18 Oct 2019 11:25:17 +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> <83lfti8ovn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="69145"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (windows-nt) Cc: cpitclaudel@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 18 12:26: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 1iLPSt-000Hoc-7C for ged-emacs-devel@m.gmane.org; Fri, 18 Oct 2019 12:26:35 +0200 Original-Received: from localhost ([::1]:37630 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLPSr-00043P-LX for ged-emacs-devel@m.gmane.org; Fri, 18 Oct 2019 06:26:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54357) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLPRl-0003IJ-6x for emacs-devel@gnu.org; Fri, 18 Oct 2019 06:25:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iLPRj-0005KU-OY for emacs-devel@gnu.org; Fri, 18 Oct 2019 06:25:24 -0400 Original-Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:46053) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iLPRj-0005KD-I7; Fri, 18 Oct 2019 06:25:23 -0400 Original-Received: by mail-wr1-x42e.google.com with SMTP id q13so672346wrs.12; Fri, 18 Oct 2019 03:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=QS2Qz1IfW3cPtnSfWHBLiq0hk7eYH0771PvOpfIPNqA=; b=ss120U/5AvqEJjxkKdmC8g+ooULSuqp+jO7Ry0MXQ+TxJTEEMfOY6o0KQFsvWaZUrL UGVZHrS31OAjxM4VhKFT68TSi0HytpbzHokdxMimNecm2JaDOGUGoTI2uaggK7I6lIH2 BBRoZWl9Nue1xZbi7vUsNUhNYywqZ8GA/ObbgScKUgoN6ZkROaNho+MyMxhxiXg0o9wa fFCO2MOBxiyQhs0Io7l4P3vyc6zPy6HWnxSqTtrG67LoKYuOGKKhxSL8jsA/ZBtl5zQG kkpNrgb291XMFyQqhSZ/B9cgUbV+XHXW3/h60TzLyqXd8wqNqbgMrE/maaWQN5UC70Yg k5YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=QS2Qz1IfW3cPtnSfWHBLiq0hk7eYH0771PvOpfIPNqA=; b=nYjEQJzRKuB6sPW7KAr1TpJ4MKY5F2cs3sXxXzgvxpg2iI1q2GJxewg4DMivcFx80y e2H9mgbbWAGvzpbTLci8M7RO+OddDeKEb7C+pV7lyOrG4N4cf7J+UDzPtyEIpyeNcAPC jb3Rkp5i4beaC/C8f5hQJJGCoyNNXVajCxTavlQWifTW51nEOspOOntl/S3T5+1A3XNl sIDeC7x8IUFN4y4nTm/UWjyZupVnoCa+iy85QN4mdec4S6EzTjYMbjOjMFT5hF5MVFOh 96Z+h8IxiiByrkSMyUFKM5U8XRgax13+cAKSBow0q5i6bvXTPOZPfsnPkwPFobhEy/Nh b92g== X-Gm-Message-State: APjAAAUsiNdzTENGQexlHMLfY4sV6GOAc/Fr8j2JQ/JxYsGjkuvFkhpx 4mGtYY1z8//ReQ/YxFa+ie6jSGsM X-Google-Smtp-Source: APXvYqym+HBFxL6KpZEYdG9vd5i72xAKC7hzTGLte5D4FUrz7Mgufx5W546XTWsavw1vrPu165yjRA== X-Received: by 2002:adf:fa87:: with SMTP id h7mr687602wrr.304.1571394321307; Fri, 18 Oct 2019 03:25:21 -0700 (PDT) Original-Received: from GONDOMAR.yourcompany.com (mail1.siscog.pt. [89.115.233.242]) by smtp.gmail.com with ESMTPSA id i1sm6808828wmb.19.2019.10.18.03.25.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 18 Oct 2019 03:25:20 -0700 (PDT) In-Reply-To: <83lfti8ovn.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 18 Oct 2019 11:00:12 +0300") X-Antivirus: AVG (VPS 191015-6, 16-10-2019), Outbound message X-Antivirus-Status: Clean X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42e 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:241198 Archived-At: Eli Zaretskii writes: > 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? It's not. It's a symptom of the same problem we've been avoiding by sprinkling explicit exemption of a particular data-type in several places. > There is no difference, not in general, not in Lisp. But there is. As Richard put it, code is data, but data not necessarily code. > 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. That's a worse solution because sprinkling exceptions around the code creates exactly the "fragmentation" problems that you and Alan seem intent on avoiding (and rightly so, I add). Now maybe in those other situations you mentioned, you didn't have a powerful enough abstraction already in place to avoid the sprinkling. But in this case you do: derived major modes and buffer-local values. > 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. As an aside, I'd like to point out that while you object to Stefans' "arguments from the future", you provide the same kind of arguments. Which is perfectly fine for me: anticipating the future is what good design is about. To your point: no, no not really. First, Flymake does **not** need to be modified to do meaningful checks of .dir-locals.el, or any other type of file for that matter. That is a fundamental misunderstanding that I don't think we've cleared yet. Like xref.el, project.el, and many others, it's designed in such a way that extending it to work with a new data type doesn't require touching the base library in any way. But, to your concrete example: say you installed Stefan's patch and you happen to write a Flymake backend (as per the manual/docstrings) for meaningful dir-locals checks, call that backend 'elis-dir-locals-checker'. You take this line: (add-to-list 'auto-mode-alist '( ".dir-locals.el" . emacs-lisp-data-mode)) And change it to read: (add-to-list 'auto-mode-alist '( ".dir-locals.el" . dir-locals-mode)) Then you add these lines (define-derived-mode dir-locals-mode emacs-lisp-data-mode "dir-locals" (add-to-list 'flymake-diagnostic-functions 'elis-dir-locals-checker nil= t)) > Anyway, I think this discussion needs to have a detailed description > of the problem, before we can continue talking about solutions. I've done by best. But I agree like 90% with you when you say "a serious problem didn't start this thread". It's true, but that problem is a symptom of bad design. Emacs lisp has the exact tool for the job here, we should use it. Perhaps you are thinking: "Why just not add the (if (string=3D (buffer-file-name) dir-locals-file) ...) wherever and go on with your life?" But I am thinking exactly the same about Stefan's patch. Jo=E3o