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: Sun, 20 Oct 2019 09:17:37 +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> <83lfth6p0y.fsf@gnu.org> <7f141905-6be3-2c21-e2af-b5926dd80223@gmail.com> <83a79w7rg6.fsf@gnu.org> <38522c1f-8127-0560-7cc5-7bdce849e650@yandex.ru> <831rv86kcg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000000fb9bc0595533482" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="24496"; mail-complaints-to="usenet@blaine.gmane.org" Cc: =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= , emacs-devel , Stefan Monnier , Dmitry Gutov To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 20 10:19:06 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 1iM6Qb-0006C3-Kw for ged-emacs-devel@m.gmane.org; Sun, 20 Oct 2019 10:19:05 +0200 Original-Received: from localhost ([::1]:54578 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iM6QZ-0004Vj-Qd for ged-emacs-devel@m.gmane.org; Sun, 20 Oct 2019 04:19:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54719) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iM6PX-0004VR-Ns for emacs-devel@gnu.org; Sun, 20 Oct 2019 04:18:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iM6PW-0003VP-Hx for emacs-devel@gnu.org; Sun, 20 Oct 2019 04:17:59 -0400 Original-Received: from mail-il1-x136.google.com ([2607:f8b0:4864:20::136]:40634) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iM6PS-0003PK-DQ; Sun, 20 Oct 2019 04:17:54 -0400 Original-Received: by mail-il1-x136.google.com with SMTP id d83so771319ilk.7; Sun, 20 Oct 2019 01:17:53 -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=NQ1LdKv/3dqbP6dULE65yDqLWUiYKRRa7okItV7FlEg=; b=gz2/fJmCN/fBhO1ddpsLh4rDao07YrQB46IuILCzH+ZKvvfLMquZ19kt6kDZj15LNe K5p+DU2OLPjg/af8G/pPLJWP7Pt4o6I79OeUljuNR+6N/EhLyIgSK8Z9TWZ2jy3gO8Vv 9+hoq+O+HL2v59yf1IAsbryfykM3F1Izl+C9P2ZmMXY9vuQdlJKHZQn2cdBtWMvO4dxe s7sOfacsYHKhpsTaFrf4nHyjBtmixVWze6DyEC2UlncCK+tvjS2no6oDnAripR58I401 a0x0YDCI/EQySWvPXbgMS/wJMRidcVB4gv13Xa8CHm7bAIOhrj/AaItst8mE3yz7zp91 Tzdw== 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=NQ1LdKv/3dqbP6dULE65yDqLWUiYKRRa7okItV7FlEg=; b=c2Yur1/aniWjPr85MsktWXhmCbm5gRfbwi6m0cGOBg491n8tYN2LUdi1oZBow4sDDl fpTJuVCDTch5DLN0jfPeRF2FIWGDAt0EYjohWZY+mh5EkDeq+yCvpOGmS3zBeoD8cQg8 nlW9X8vHvTfrvPzRpfbuvEDhf1iq3h/bfQXqBITkgqx+kfzHVH6Rk9hcdVhB3FUhxIS8 aH/ss9sW9e9nAQTX0sHaErX09jqqWIyy+yxHo4AyGF8bPOY9nU0SMHrpuG9wMd42EAlH BqW1jAuHWiq6IT6kjEA22ZhJFC/CJBXb19i04oOa3tK+6al6BZ/VmC0YuQF4rDFoI/D6 hJ9g== X-Gm-Message-State: APjAAAWJPr9Yfo5XRmoIEJ/EXWkVlO32YqtNwPEozASr3HWT2KEB6cxF yWGM3ghfp9CSCoiffXBUmT+TNq4THmsUnB4WCfUR22T6Z8Q= X-Google-Smtp-Source: APXvYqxGs8amwK+uYyAo+g3nCUN0KasOeTW+66OIHsRb+EnhZy0oL3Y3S5031k+vfoIZk1MNzoL4nlZmYEjkbL5s8wo= X-Received: by 2002:a92:dac4:: with SMTP id o4mr21050470ilq.137.1571559471821; Sun, 20 Oct 2019 01:17:51 -0700 (PDT) In-Reply-To: <831rv86kcg.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::136 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:241248 Archived-At: --0000000000000fb9bc0595533482 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 20, 2019 at 6:45 AM Eli Zaretskii wrote: > > > will have to devise some way of turning on that new mode automaticall= y > > I don't think that should be a prerequisite. > Why not? It would be very unusual and inconvenient for a major mode > to require that it be manually turned on to be useful. Do we have any > other major mode that needs that? Of course we do, and that's why we provide so many flexible ways to let users fix it. I don't control the file names and extensions of most of the files I work with, but I do control my Emacs's variables. > If we can automatically generate the mode cookie, we can automatically > generate any other file-local variable we might need, like > 'no-byte-compile: t' or the setting for an Xref backend. Then you'd have a proliferation of identical buffer-local variable blocks. And I know a good way to refactor that ;-) But cookie generation would only be for very tight cases, I think, if any at all. Because for files whole filenames and/or standard locations we know, such as dir-locals.el, bookmarks, ido-last, recentf, tramp-something, etc. we can just leverage the existing auto-mode-alist and magic-mode-alist. _And_ we can do always it incrementally, we _dont_ have to hurry or rush to decisions for this change to start being useful. Jo=C3=A3o --0000000000000fb9bc0595533482 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Oct 20, 2019 at 6:45 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > > will= have to devise some way of turning on that new mode automatically
> = > I don't think that should be a prerequisite.
> Why not?=C2= =A0 It would be very unusual and inconvenient for a major mode
> to r= equire that it be manually turned on to be useful. Do we have any
> o= ther major mode that needs that?

Of course we do, and that's why= we provide so many flexible ways to let
users fix it.=C2=A0 I don't= control the file names and extensions of most of
the files I work with,= but I do control my Emacs's variables.

> If we can automatic= ally generate the mode cookie, we can automatically
> generate any ot= her file-local variable we might need, like
> 'no-byte-compile: t= ' or the setting for an Xref backend.

Then you'd have a prol= iferation of identical buffer-local variable
blocks.=C2=A0 And I know a = good way to refactor that ;-)

But cookie generation would only be fo= r very tight cases, I think, if
any at all.=C2=A0 Because for files whol= e filenames and/or standard locations
we know, such as dir-locals.el, bo= okmarks, ido-last, recentf,
tramp-something, etc. we can just leverage t= he existing auto-mode-alist
and magic-mode-alist.

_And_ we can do= always it incrementally, we _dont_ have to hurry or rush
to decisi= ons for this change to start being useful.

Jo=C3= =A3o
--0000000000000fb9bc0595533482--