From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#40573: 27.0.90; flymake-mode broken in scratch buffer Date: Tue, 14 Apr 2020 12:48:55 +0100 Message-ID: References: <835ze4lsr1.fsf@gnu.org> <831roslq62.fsf@gnu.org> <87sgh89r78.fsf@mail.linkov.net> <83lfn0j92e.fsf@gnu.org> <87imi39e8w.fsf@mail.linkov.net> <83h7xmipi7.fsf@gnu.org> <83d08ai9vd.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006f710905a33ec9a6" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="26931"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 40573@debbugs.gnu.org, Juri Linkov , Stefan Monnier , Dmitry Gutov To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 14 13:50:18 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jOK53-0006sm-VI for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 14 Apr 2020 13:50:18 +0200 Original-Received: from localhost ([::1]:58826 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jOK53-0000ZJ-0H for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 14 Apr 2020 07:50:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56945) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jOK4p-0000UB-Lz for bug-gnu-emacs@gnu.org; Tue, 14 Apr 2020 07:50:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jOK4o-0003GK-BV for bug-gnu-emacs@gnu.org; Tue, 14 Apr 2020 07:50:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50041) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jOK4o-0003G8-8O for bug-gnu-emacs@gnu.org; Tue, 14 Apr 2020 07:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jOK4o-0004XU-7E for bug-gnu-emacs@gnu.org; Tue, 14 Apr 2020 07:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Apr 2020 11:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40573 X-GNU-PR-Package: emacs Original-Received: via spool by 40573-submit@debbugs.gnu.org id=B40573.158686495417387 (code B ref 40573); Tue, 14 Apr 2020 11:50:02 +0000 Original-Received: (at 40573) by debbugs.gnu.org; 14 Apr 2020 11:49:14 +0000 Original-Received: from localhost ([127.0.0.1]:33354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOK41-0004WM-TP for submit@debbugs.gnu.org; Tue, 14 Apr 2020 07:49:14 -0400 Original-Received: from mail-il1-f181.google.com ([209.85.166.181]:41047) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jOK40-0004W9-5Z for 40573@debbugs.gnu.org; Tue, 14 Apr 2020 07:49:12 -0400 Original-Received: by mail-il1-f181.google.com with SMTP id f82so8253462ilh.8 for <40573@debbugs.gnu.org>; Tue, 14 Apr 2020 04:49:12 -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=CcGsrZR3RCnfGvtwoKGbcWsZwdxosONyzRSdDmpsag4=; b=hR/kipR3+QOXhQAs/l27N5TCaiiybIP+vet5YqqiDeP34bHEOE35iZVY1GwjRuR9cf Qlqk3JnMNlSLMnwasYXDWOp3EdUxkUrzXVjzoVAIt+yFA+4rbRc0V6PJichcEbUiQ0CX abawva5ghYalwDO3oaD7ZZcSYD+5hR8RQaXk1XERATWH4oP8baljlkSKt67IAQUzLLOQ ECYPaj66jjfDkDxJiEwpynQk2Njq3a5bKcepMyO3o/um/wvrV1n5fkVAP2RdZEZquMPi 9QCPJzG+U96q26LyCv7SIjDlOEI5FRafOChENr/vcIgKoEL9o/FkHSbO8jAnDToE9v9V JVIw== 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=CcGsrZR3RCnfGvtwoKGbcWsZwdxosONyzRSdDmpsag4=; b=GdUvYXXODS86TOk+P+m5jzjOZV8YlT8PsPrwiERUC6ECQH8cXrhrsUS0wCBCubG8e9 +Crask/mCNvrEkj+W7iGUYeUmdOKZp2Jb0xf9Km/wzOdrHzdZGvh+LMyoWZNSwLVKP6i TJLXnKmFmCHtJzPjb9z3KtdmqjK36P/ZaC6VOW0wI4pbV19gFKJPdrac9uwkhXE5Q7ki MMcwmCBtAX4BdLWM3yhpk4hSoN0a/9/ooqdu4mhv8jqTDdKWJnsaGI6GlZbj5mdfQq25 tgfj0kPb5pgeprDgxZWtvNO0tqeZQPzYahugEcFxg2gZjFIvghQGLCC+sl+D6Lz5ml4s GPyw== X-Gm-Message-State: AGi0Pub3G00we5szSVp/4738u8+pqW3ujeJl59llWXvcV1B69Uzu3MsT FN4xrc6fEwiS0kPsgTLMxJp+/SDKYSPhwjB9CGI= X-Google-Smtp-Source: APiQypKE99BpMpSN28IaehFdUZBwDmH0h+luRdHZPgQl4fUIkPHEw+zrMNdQ4o+K+iUpTZIR90IOS4AH5THEP0up4yU= X-Received: by 2002:a92:c00c:: with SMTP id q12mr21304854ild.125.1586864946375; Tue, 14 Apr 2020 04:49:06 -0700 (PDT) In-Reply-To: <83d08ai9vd.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:178353 Archived-At: --0000000000006f710905a33ec9a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 14, 2020 at 12:29 PM Eli Zaretskii wrote: > > From: Jo=C3=A3o T=C3=A1vora > > Date: Tue, 14 Apr 2020 09:48:43 +0100 > > Cc: Juri Linkov , 40573@debbugs.gnu.org, > > Stefan Monnier , Dmitry Gutov < > dgutov@yandex.ru> > > > > > How would you propose to identify these files for turning on this > > > special mode? They don't seem to have a clear-cut set of extensions > > > and/or file names. > > > > One thing I don't understand is why is this important at all. > > It is only important if we want this new mode to be turned on > automatically in such files. If we want these files to be visited in > Fundamental mode, or some other random mode due to their extensions, > then this is indeed not important. But then .dir-locals.el, for > example, will be visited in emacs-lisp-mode, something I thought we > wanted to prevent? > Yes, we do. And it's trivial to add an entry for .dir-locals.el to auto-mode-alist for that, as was suggested often. In hindsight choosing .el for that file wasn't great, but it's not very bad either. For files under our control, we have more options, including mode cookies and doing nothing. > Examples such as recentf, tramp, and ido files had already been given. > > Again please don't base any implementation on those "details": they are > > just an example. The universe of lisp data files is much greater than > > that. > > We must have some body of common traits of these files to program a > mode that is suitable for them. > That's easy: lisp forms that can be `read`. But it's even easier to find that "suitable mode" if you think about the problem differently, as a "differences to emacs-lisp-mode" problem. Let me explain. Basically we just need to split emacs-lisp-mode in two. I'd say flymake and imenu and xref and eldoc stay in emacs-lisp-mode, all the rest stays in lisp-data-mode. After the inheritance is setup, emacs-lisp-mode is unaffected, but lisp-data-mode can be used independently. But if we don't get the "split point" right the first time, it's very easy to move things across the border to get a better lisp-data-mode _without_ adversely affecting emacs-lisp-mode in any way. Stefan's approach that I linked to is a good first approach to that split point. Again, we can adjust it afterwards. Jo=C3=A3o T=C3=A1vora --0000000000006f710905a33ec9a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Apr 14, 2020 at 12:29 PM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Jo=C3=A3o T=C3=A1vora <<= a href=3D"mailto:joaotavora@gmail.com" target=3D"_blank">joaotavora@gmail.c= om>
> Date: Tue, 14 Apr 2020 09:48:43 +0100
> Cc: Juri Linkov <juri@linkov.net>, 40573@debbugs.gnu.org,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Stefan Monnier <monnier@iro.umontreal.ca>, Dmit= ry Gutov <dgutov@y= andex.ru>
>
> > How would you propose to identify these files for turning on this=
> > special mode?=C2=A0 They don't seem to have a clear-cut set o= f extensions
> > and/or file names.
>
> One thing I don't understand is why is this important at all.

It is only important if we want this new mode to be turned on
automatically in such files.=C2=A0 If we want these files to be visited in<= br> Fundamental mode, or some other random mode due to their extensions,
then this is indeed not important.=C2=A0 But then .dir-locals.el, for
example, will be visited in emacs-lisp-mode, something I thought we
wanted to prevent?

Yes, we do.=C2=A0 An= d it's trivial to add an entry for .dir-locals.el
to aut= o-mode-alist for that, as was suggested often. In hindsight
choos= ing .el for that file wasn't great, but it's not very bad either.

For files under our control, we have more options, = including
mode cookies and doing nothing.

> Examples such as recentf, tramp, and ido files had already been given.=
> Again please don't base any implementation on those "details&= quot;: they are
> just an example.=C2=A0 The universe of lisp data files is much greater= than
> that.

We must have some body of common traits of these files to program a
mode that is suitable for them.

That= 9;s easy: lisp forms that can be `read`.

But = it's even easier to find that "suitable mode" if you think
about the problem differently, as a "differences to
emacs-lisp-mode" problem. Let me explain.

Basically we just need to split emacs-lisp-mode in two.
I'd= say flymake and imenu and xref and eldoc stay in
emacs-lisp= -mode, all the rest stays in lisp-data-mode.
After the inheritance is = setup,=C2=A0 emacs-lisp-mode is
unaffected, but lisp-data-mo= de can be used independently.=C2=A0

But if we don't get the "split point" right the firs= t time, it's
very easy to move things across the border = to get a better
lisp-data-mode _without_ adversely affecting emac= s-lisp-mode
in any way.

Stefan'= s approach that I linked to is a good first approach
to that spli= t point.=C2=A0 Again, we can adjust it afterwards.

Jo=C3=A3o T=C3=A1vora
--0000000000006f710905a33ec9a6--