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: Mon, 21 Oct 2019 09:25:00 +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> <5c9ce9a7-aaa7-8299-e5be-498cb4f2b173@yandex.ru> <8336fo6koq.fsf@gnu.org> <09a6f3b6-6743-fe31-4be8-9283e59753fd@yandex.ru> <83eez64nw3.fsf@gnu.org> <8336fm4li7.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002e0d2e0595676cbc" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="180784"; 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 Mon Oct 21 10:25:54 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 1iMT0k-000klf-7Y for ged-emacs-devel@m.gmane.org; Mon, 21 Oct 2019 10:25:54 +0200 Original-Received: from localhost ([::1]:35766 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iMT0i-0000Yt-8M for ged-emacs-devel@m.gmane.org; Mon, 21 Oct 2019 04:25:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53427) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iMT0B-0000Wh-0g for emacs-devel@gnu.org; Mon, 21 Oct 2019 04:25:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iMT09-0003lX-K5 for emacs-devel@gnu.org; Mon, 21 Oct 2019 04:25:18 -0400 Original-Received: from mail-il1-x134.google.com ([2607:f8b0:4864:20::134]:32914) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iMT05-0003kN-PX; Mon, 21 Oct 2019 04:25:13 -0400 Original-Received: by mail-il1-x134.google.com with SMTP id v2so11220177ilm.0; Mon, 21 Oct 2019 01:25:13 -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=LPuyJ0mBz6zoBq/bdpRt9OCiyHVDAO/U/xsw9MwLY6U=; b=A17QQKPG0WE5Std/7hzuy5b9iJkrO18MdtZP+xklbQ4rDTCI9TGWnFi7QgwN624XvM O/CJPwGwdDUkQq7x4gdV5xQ8cDy92I2Lo6a0YeYssoHSYHPZjsduNHDn9Qf9qRAPgoBG IwiqfSOM+pdi2saKlAhQnepLoWW++P5EfQYH6wlBg5T4rwI0pJ7yJvW10vub2qzoylEe DFab/MNkjWwu9W6sioP+QfJwP0Lq7e5L9htfsNkGyhR5k0l1TxSJpUcKPdceCKlzBjLH bQZMVy+CaBqam6aFmwAjoBIc/7tyYIukMJtF5A083ATVDTTkEseeqZkKqLFNhoGTFbFU /LCA== 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=LPuyJ0mBz6zoBq/bdpRt9OCiyHVDAO/U/xsw9MwLY6U=; b=NQJ+9nQjwjc9DYw5L/3ryDlYqPHEZdSlsfu5GLzWwjnorrU0064ty+WnsE3JujfQSJ rimw0P0Bg62ZVHCanWUwdJEjPnUZZ2irQ8Wti4X8Q/68XUk5CR3JSlww11TC7OCr9Nyq utiH2L/bQUffB7LqaAJ/Y5W8sFaMDaEeBwl+tZochsFlPSfJfJzJjlEWJlfYdUTeg/ga nGS0HjBJbMTW51GYuxQU+BNRjZwVJqLCAdf30L2AgcWkn21P9xxKzmXjqCTbaE9C+Syo Y2li4vTmsGqZZ47E3G/Ra90nAhWK3zzHGmq9Y2f9/Mh2bRe6DVWAX4DYngjQgpdOB08n jD1A== X-Gm-Message-State: APjAAAUlsqsEAtPK5KPK/w0GWCqyTB91xTpnCidSva32Q2Cf6zn5XB8+ Hmepb7nnXWL1ZaVfsIEWIoUEQWNWZ0cZwBB1n9g4iSrho7o= X-Google-Smtp-Source: APXvYqza5QIruGC2+guSEXisVpllxrVmewGvEtCfZgAZ8j9ep7J+Zhsa/GCw/SOviF/IP2fosaOiCpLmUCUyfBPariI= X-Received: by 2002:a92:dd88:: with SMTP id g8mr24980045iln.199.1571646312679; Mon, 21 Oct 2019 01:25:12 -0700 (PDT) In-Reply-To: <8336fm4li7.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::134 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:241283 Archived-At: --0000000000002e0d2e0595676cbc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 21, 2019 at 8:15 AM Eli Zaretskii wrote: > I don't agree that it's a nice feature. I don't even understand why > we give up so easily on elisp-mode support for such "data files", > Because elisp-mode is for emacs-lisp programs, not lisp data. Can you concede that, or is that still controversial? If we want to make it work for lisp data like you propose we have to conditionally remove things from it. Which is possible, but ugly, and downright impossible when those things come from emacs-lisp-mode-hook. And, in your patch, we would be tying it to a file name, which is needlessly hacky. It's much better to recognize the part of emacs-lisp-mode that is _common_ to data (and there is a lot) and extract that into a new function. That that function is called "a major mode" is just a name, it's nor a "major thing" at all, it's just 5-6 lines and a 1kB table. something that should be quite natural, and instead want some > "inferior" mode based on file names and manual turning on of the mode. > It simply feels wrong, as file names have nothing to do with the > actual issue of doing TRT with Lisp data. > > But this all was already said many times, we just keep going in > circles with no new arguments anywhere in sight. > I've (and we've) summarized the arguments, given "arguments from the future" and replied to your own "arguments from the future". But it is, by definition, impossible to argue with "gut feeling" and "feels wrong" or "should be natural". I just don't know how to talk to your gut (or even if I want to). It's because I want to believe that Emacs is a rational place, that I ask to rebut the concrete evidence that is being presented here, or yield to it. If it helps, I concede that file names are indeed an orthogonal problem. They are simply one of the best heuristics we have to guess the file content. Take filenames out of the equation, please. We can discuss a better heuristic later, say a machine learning one (it's all the rage nowadays). For now, just focus on the pros and cons of making a major mode for lisp data. Jo=C3=A3o --0000000000002e0d2e0595676cbc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Oct 21, 2019 at 8:15 AM Eli Zaretskii <eliz@gnu.org> wrote:
I don't agree that it's a nice feature.=C2=A0 I don't even unde= rstand why
we give up so easily on elisp-mode support for such "data files",=

Because elisp-mode is for emacs-lisp p= rograms,
not lisp data. Can you concede that, or is that sti= ll controversial?

If we want to make it work for l= isp data like you propose we
have to conditionally remove th= ings from it.=C2=A0 Which is possible,
but ugly, and downright i= mpossible when those things come
from emacs-lisp-mode-hook.
=

And, in your patch, we would be tying it to a fil= e name, which
is needlessly hacky.

I= t's much better to recognize the part of emacs-lisp-mode that is
_common_ to data (and there is a lot) and extract that into a
=
new function.=C2=A0 That that function is called "a major m= ode" is just
a name, it's nor a "major thing" = at all, it's just 5-6 lines and
a 1kB table.

something that should be quite natural, and instead want some
"inferior" mode based on file names and manual turning on of the = mode.
It simply feels wrong, as file names have nothing to do with the
actual issue of doing TRT with Lisp data.

But this all was already said many times, we just keep going in
circles with no new arguments anywhere in sight.

<= /div>
I've (and we've) summarized the arguments, given "a= rguments
from the future" and replied to your own "= ;arguments from the
future".

<= div>But it is, by definition, impossible to argue with "gut feeling&qu= ot;
and "feels wrong" or "should be natural&q= uot;. I just don't know
how to talk to your gut (or even if I= want to).

It's because I want to believe = that Emacs is a rational place,
that I ask to rebut the conc= rete evidence that is being
presented here, or yield to it.<= /div>

If it helps, I concede that file names are indeed = an
orthogonal problem.=C2=A0 They are simply one of the best= heuristics
we have to guess the file content. Take filenames out= of the
equation, please. We can discuss a better heuristic = later, say
a machine learning one (it's all the rage now= adays).=C2=A0 For now,
just focus on the pros and cons of making = a major mode for
lisp data.

Jo=C3= =A3o
--0000000000002e0d2e0595676cbc--