From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Add a separate mode for .dir-locals.el Date: Fri, 18 Oct 2019 09:11:19 -0400 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> <831rvb9m9d.fsf@gnu.org> <83mudy8p99.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="258554"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: cpitclaudel@gmail.com, joaotavora@gmail.com, 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:16:29 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 1iLS7J-00158J-1p for ged-emacs-devel@m.gmane.org; Fri, 18 Oct 2019 15:16:29 +0200 Original-Received: from localhost ([::1]:39868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLS7H-0001li-Ay for ged-emacs-devel@m.gmane.org; Fri, 18 Oct 2019 09:16:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48252) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iLS2V-0006hT-9H for emacs-devel@gnu.org; Fri, 18 Oct 2019 09:11:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iLS2T-00036c-OU for emacs-devel@gnu.org; Fri, 18 Oct 2019 09:11:30 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:32104) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iLS2S-00034w-0T; Fri, 18 Oct 2019 09:11:28 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D8A02449116; Fri, 18 Oct 2019 09:11:26 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 62CCE449114; Fri, 18 Oct 2019 09:11:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1571404285; bh=R081MDX8i0b9Wq+vlRnGbb4t9NkhzzxXUgyDfe9Ami4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=oUdht83D/dcOqBgooAJdugsDBMX1hilmBXMhdUn/9UxNHN5K1mAxYa7wfDEMD8Zow GMGrGDd7X9fuOZsLr2y0dKib8FXfFigKXjYQ0VZ7vheUOAQ1KjRjnP1/7+M8YBPxRc /GpGAd3n9u1RktyGmkQW0M7KPl+oIAOfXh0HaBxMMtx4cJOAqC4W+5knQdQ09q1TT2 EkVIpthESxGPW7ypxITeJDMg1Aocp4NnaGIsfhY2f8HK/3bxs8nEz+4XzMBhqcbo5V KwsKh0zGWZpcr+QhypdrSfLopbjgdVNl90xhriXYMoFkBNC9T3a2F1eNc0sguZnE5T TNKVo2P+7NHqA== Original-Received: from pastel (unknown [216.154.15.203]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id ED58C120F98; Fri, 18 Oct 2019 09:11:24 -0400 (EDT) In-Reply-To: <83mudy8p99.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 18 Oct 2019 10:52:02 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 132.204.25.50 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:241202 Archived-At: >> ... other things we may want to fix such as the M-C-x binding which >> makes no sense in .dir-locals.el, or the presence of "Byte-compile >> this file" in the menu, ... > > The former might make sense, because .dir-locals.el can include 'eval' > forms, right? No, because those forms won't start in column 0, so C-x C-e might work, but C-M-x won't. > If we care about the latter, it can be handled by being > sensitive to 'no-byte-compile: t' instead. You really want to have to add `no-byte-compile: t` to every .dir-locals.el instead of adding an auto-mode-alist rule? > Or even compare with the file name, as bytecomp.el already does, as do > other places. Yes, we can come up with all kinds of hacks, of course. Not sure why you'd want to do that instead of using the clean&simple approach of a separate major mode so you can rely on standard mechanisms like auto-mode-alist. > This all sounds to me like "arguments from the future": we don't yet > have any substantial reasons to define a major mode, but we are trying > hard to think of any potential reason we might have in the future. I don't understand what you're getting at. You seem to think that creating a major mode is a big deal. It's not. I don't need any special reason to define a major mode. It's not like it's a complex thing to do with far reaching consequences. It's a small matter of writing the following three trivial lines of code: (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 changing (define-derived-mode emacs-lisp-mode prog-mode "Emacs-Lisp" (define-derived-mode emacs-lisp-mode emacs-lisp-data-mode "Emacs-Lisp" and moving three other lines. This in itself makes no visible difference to users at all, and it's very easy to see that it's the case (the main impact is likely the allocation of about 1KB for the syntax table). This then lets us solve the original problem by adding a single line to auto-mode-alist which can be trivially shown to only affect those files that happen to match the regexp we choose to use there. So they're all simple and safe steps. Creating a major mode is cheap and easy. No need to be afraid. Even if it inserts itself inside a pre-existing part of the hierarchy as is the case here. Stefan