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 14:43:36 +0100 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="116365"; 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 15:45:17 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 1iLSZA-000U5V-FJ for ged-emacs-devel@m.gmane.org; Fri, 18 Oct 2019 15:45:16 +0200 Original-Received: from localhost ([::1]:40280 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLSZ8-0001IX-Nv for ged-emacs-devel@m.gmane.org; Fri, 18 Oct 2019 09:45:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53920) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLSXf-0007vK-N1 for emacs-devel@gnu.org; Fri, 18 Oct 2019 09:43:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iLSXe-0002SJ-9P for emacs-devel@gnu.org; Fri, 18 Oct 2019 09:43:43 -0400 Original-Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:32987) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iLSXe-0002Qi-2U; Fri, 18 Oct 2019 09:43:42 -0400 Original-Received: by mail-wr1-x434.google.com with SMTP id b9so6352094wrs.0; Fri, 18 Oct 2019 06:43:41 -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=UHyoHaKGSw6x3s8G/j4fsvpJhlvcg3f4Xvn59NdDlnk=; b=oA9q2RgKYJ12FGoTkytEzcfWqzmATlL+IooenHSe4pPKGZiCGWWHhBMXFlD0dxTI1m JqyTK5OeaTs4vQQ/KlQwmmaAB0b/9qrhxOK4Ad0CM2R2HSl3pxxDV9KrCrL0yQ45NtyB 36o+ZQEMRZhOtbdTGrmc09zeSL405OMpoNaB6n/BZn3TOb7YD+f05k+oJAyHsx0/BVVM olKl1pVaaG42mNHEd4IOpakLVHvyTWxzMCJGmpCHv/Wqn9sC3IKnaL/NfKsGQO5VUjGM EnYzcgVOqFkrjEZPebmZje7LW8kCWsSEdJ//jCVVfqD4FaI0xTYkYs6gpwNKRDuNqJaY Ftdg== 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=UHyoHaKGSw6x3s8G/j4fsvpJhlvcg3f4Xvn59NdDlnk=; b=lyaGcOXvjSzBQMz0xbLo4xAyMksyG424mJI4tQHJGxx30B0RYtY8zRQIu1rzYxsqq1 1hXcj54vPiV6LBU5BjTAD6qtddRJtnTMHV37UrcbA2Bmj4IhOdsxJuUCXj+TTDXXMYBD bufE35ajHR3JNsCAtJ0xouSHR+csINIG0fbddCov1oNyOAxSYAmoKHCINtoRDEAUKbdu t9Pykvc51/3mFZ2o06/J7oHJyIt17+H/dEAu0Vq+qxV9j60LGe+eZgAgNvEXwXPhvehq 37D4TKMzPzTaEhalHa7xSkUxo40jWi0nZZV4HP0qqtI2DBzpL7XnhQXVI6Tj1YzLNmKB h6BQ== X-Gm-Message-State: APjAAAVtAvyZCeeLvoEaKy6rsRxD5Bsic8KG/MehpbOWqLHpj+6tyX2D WPwd8UzPflEvPMxBslf97Ny8UUG3 X-Google-Smtp-Source: APXvYqzQtCRjN8xLjrvdBbh8DHX7OqQsj5quuVjqd+E6kIdOfyWSjMnHD5YS8ICbARFIK1QDohJCTQ== X-Received: by 2002:adf:9486:: with SMTP id 6mr7155301wrr.28.1571406219784; Fri, 18 Oct 2019 06:43:39 -0700 (PDT) Original-Received: from GONDOMAR.yourcompany.com (mail3.siscog.pt. [195.23.29.18]) by smtp.gmail.com with ESMTPSA id c21sm4920494wmb.46.2019.10.18.06.43.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 18 Oct 2019 06:43:38 -0700 (PDT) In-Reply-To: <83d0eu8c80.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 18 Oct 2019 15:33:35 +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::434 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:241206 Archived-At: Eli Zaretskii writes: >> From: Jo=E3o T=E1vora >> Cc: monnier@iro.umontreal.ca, cpitclaudel@gmail.com, emacs-devel@gnu.o= rg >> Date: Fri, 18 Oct 2019 11:25:17 +0100 >>=20 >> > 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. > Where? Maybe I've missed that, so please summarize it for me. Where? Ufff... OK. In this thread, I've been trying to tell, you many times over, constructively, that I think this is a _symptom_ of a larger problem, namely a failure to correctly model differences between lisp code and data. Nevertheless here is, one last time, for your benefit (and hopefully ours, too), a summary: - The starting complaint is that Flymake doesn't make sense for dir-locals.el, IOW you get bogus and distracting diagnostics for these dir-locals.el (by the way, the possibility of witnessing this for yourself, is exactly one M-x flymake-mode RET away from your fingers); - But the problem also probably impacts whoever has no option but to add things to `emacs-lisp-mode-hook` that don't pertain to emacs-lisp data, but only emacs-lisp programs. Modes such as Flycheck or which-func-mode or whatever people have in their .emacs; - And we've also had others mention that this doesn't happen just for dir-locals.el files but also others such as recentf, tramp, ido files, and probably many other specialized data files that arent in Emacs core. The problem here is, whenever people try structuredly edit these files they realize all they have is emacs-lisp-mode; - Also, I've explained over and over that Flymake, or even its elisp-mode.el backends, aren't the culprit here: they apply cleanly to any emacs-lisp program, but not dir-locals.el because it does not contain an emacs-lisp program. The mode is being misapplied to that file. - Then I proceeded to explain the merits of Stefan's solution again and again, rebutting your "arguments from the future" with actual examples. So here, once again, to summarize, are the two best solutions: A) in lisp/progmodes/elisp-mode.el we do this - (add-hook 'flymake-diagnostic-functions #'elisp-flymake-checkdoc nil= t) - (add-hook 'flymake-diagnostic-functions #'elisp-flymake-byte-compile= nil t)) + (unless (equal (buffer-file-name) dir-locals-file) + (add-hook 'flymake-diagnostic-functions #'elisp-flymake-checkdoc n= il t) + (add-hook 'flymake-diagnostic-functions #'elisp-flymake-byte-compi= le nil t))) B) in lisp/progmodes/elisp-mode.el we do this -(define-derived-mode emacs-lisp-mode prog-mode "Emacs-Lisp" +(add-to-list 'auto-mode-alist '(".?dir-locals.el" . emacs-lisp-data-mo= de)) +;;;###autoload +(define-derived-mode emacs-lisp-data-mode prog-mode "Emacs-Lisp-Data" + "Major mode for buffers holding data written in Emacs Lisp syntax." + :group 'lisp + (lisp-mode-variables nil nil 'elisp) + (setq-local electric-quote-string t) + (setq imenu-case-fold-search nil)) + +;;;###autoload +(define-derived-mode emacs-lisp-mode emacs-lisp-data-mode "Emacs-Lisp" "Major mode for editing Lisp code to run in Emacs. Commands: Delete converts tabs to spaces as it moves back. @@ -241,15 +251,12 @@ emacs-lisp-mode \\{emacs-lisp-mode-map}" :group 'lisp (defvar project-vc-external-roots-function) - (lisp-mode-variables nil nil 'elisp) (add-hook 'after-load-functions #'elisp--font-lock-flush-elisp-buffe= rs) (if (boundp 'electric-pair-text-pairs) (setq-local electric-pair-text-pairs (append '((?\` . ?\') (?=91 . ?=92)) electric-pair-text-pairs)) (add-hook 'electric-pair-mode-hook #'emacs-lisp-set-electric-text-= pairs)) - (setq-local electric-quote-string t) - (setq imenu-case-fold-search nil) (add-function :before-until (local 'eldoc-documentation-function) "A" will probably fix the OP's problem it, but will run into problems if someone has stuff in their emacs-lisp-mode-hook in the conditions I explained above. "B" always fixes the problem, is cheap and solves the other problems described above, creating something that people have been asking for in the process: a major mode to conveniently edit lisp data or from which to safely derive specialized lisp data editing modes. > last I heard from you on this was that you didn't yet look seriously > at the particular problem, and that you thought it was due to byte > compilation. Is there something more specific? > >> 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. > > I would like to proceed to pretesting Emacs 27.1 and releasing it, so > I would like to avoid any changes that are not strictly needed. > Please help me in this. I've been trying. Up there are two summarized diffs. Do this: if we've already branched 27.1 (have we?) then I suggest A goes to the release branch with a "dont merge" thingy and B goes into master. But if you read B carefully (and it's really not hard, it's 15 lines of change) you'll arrive at the conclusion that it's pretty safe. Your choice. Jo=E3o