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: Fri, 17 Apr 2020 11:21:50 +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> <878sivdsjn.fsf@mail.linkov.net> <83r1wmd2u0.fsf@gnu.org> <83a73acted.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008e02c605a379eb68" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="113960"; 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 Fri Apr 17 12:23:14 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 1jPO9R-000TXb-Dv for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Apr 2020 12:23:13 +0200 Original-Received: from localhost ([::1]:45084 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPO9Q-0003aE-Ge for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Apr 2020 06:23:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37207) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jPO9H-0003YO-Jw for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2020 06:23:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jPO9G-0005jb-IM for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2020 06:23:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56656) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jPO9G-0005jR-FZ for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2020 06:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jPO9G-0001fJ-Bs for bug-gnu-emacs@gnu.org; Fri, 17 Apr 2020 06:23: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: Fri, 17 Apr 2020 10:23: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.15871189286299 (code B ref 40573); Fri, 17 Apr 2020 10:23:02 +0000 Original-Received: (at 40573) by debbugs.gnu.org; 17 Apr 2020 10:22:08 +0000 Original-Received: from localhost ([127.0.0.1]:39965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPO8O-0001dX-Ex for submit@debbugs.gnu.org; Fri, 17 Apr 2020 06:22:08 -0400 Original-Received: from mail-io1-f50.google.com ([209.85.166.50]:44412) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jPO8N-0001d8-Dh for 40573@debbugs.gnu.org; Fri, 17 Apr 2020 06:22:07 -0400 Original-Received: by mail-io1-f50.google.com with SMTP id h6so1714828iok.11 for <40573@debbugs.gnu.org>; Fri, 17 Apr 2020 03:22:07 -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=2wVZuzLIQOk+jNPS4frQYa362W7eVD3EPzaYUpo2nwQ=; b=RdR6uo8bHH+dP9aQ5wwvxdGxAgU0627owcvhi3FX5t9Y/MJHSguLslRYaW7QydZhcO BHOrKky9RBAeLd50iFBUmnQXoP2tU6HE+uN8i1Jgww5rzHpxyFgQ8VuLny3nlxFl3KjO e9nNngolxWSrFEQrmAqEnq6Zx+1iUacjWYGgKPp0r0sfUkwzpFapwk2/Yo6CqGI5shup 9fgk4J5pxm33ZtOp4hS3/LeFaj3IjWIKMvQPEg1ybNvUaIuqX6Vdx6ksN7iOiYx/4Z/w aWf0bHJEo3rqckJooUE8fjFcl1DeB2RgcFlFgBVxGeIXAuUMScRM35ivuL1FdzD7FqK0 QmUw== 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=2wVZuzLIQOk+jNPS4frQYa362W7eVD3EPzaYUpo2nwQ=; b=lllBxiZD7cWa2zMDjB6zB3S0YRwgdMT2OFpi7N4Z95nRD9EFfDPI0n3nJTO7r1bnAt R4wc8cO8Yyq9DzdZkBMmIFtd59JqsfEzBPiXqGGBlH1cEoC2+8n8FcPrRmpA3bQSHabu 3/eeJG5xTwtmEzlemmsI/1MS98TDYoz4SFMWQsWeJX4CbLg4DSYC4WFebquncRhtlYgg PBHhSnI8X7RgajiLbMSjOHV12vjUwBiau3r/mzmqkrkf1CvuJ+6NItjefIopu4PKtX3r bYkF4uQigtjBPPRRjLZFCZ5ZcYDWNOVuTurJ06YGRPmJLN6Uu8mCVWwAtxOuAtpLegb7 iiMg== X-Gm-Message-State: AGi0PuZrxKkWRjzOoWsM3d/yI4Eo2571OLSta6lfltE7Xo36EWV9jTWG KqUN95mkPMKrQ95vhP0JrgWYhXMND8WrJIOjFpw= X-Google-Smtp-Source: APiQypJDBPlR85of/9x4bvlNhwRpYCgfI+5xKWhSSILa30LZWHHvZsJ1fNNUdmr4NH9igEe4YCfGJtgvHTjze7cdXBI= X-Received: by 2002:a02:7b21:: with SMTP id q33mr2589533jac.24.1587118921874; Fri, 17 Apr 2020 03:22:01 -0700 (PDT) In-Reply-To: <83a73acted.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:178496 Archived-At: --0000000000008e02c605a379eb68 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 17, 2020 at 11:13 AM Eli Zaretskii wrote: > > > Shouldn't we just take a "best-effort" approach here? > > I think you will find that opinions differ on what is "best effort" in > this context. Which is completely fine, we don't need to agree on > such issues. > Indeed, we don't need to, but here's my take on anyway, followed by a question. For me, best effort here means: do something self-contained that brings some good and brings no harm. I think introducing lisp-data-mode is _exactly_ in those conditions. That's not to say we can't use do _more_ good as we extend our efforts. But we shouldn't let those ambitions stifle the initial deed, smaller, but unquestionably positive. So I'm thinking of introducing lisp-data-mode later on in master, following Stefan's patch. And using it only for `dir-locals.el` for now (and for my own files of course). Is that OK with you? --=20 Jo=C3=A3o T=C3=A1vora --0000000000008e02c605a379eb68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Apr 17, 2020 at 11:13 AM Eli Zare= tskii <eliz@gnu.org> wrote:

> Shouldn't we just take a "best-effort" approach here?
I think you will find that opinions differ on what is "best effort&quo= t; in
this context.=C2=A0 Which is completely fine, we don't need to agree on=
such issues.

Indeed, we don't need = to, but here's my take on anyway,
followed by a question.
=

For me, best effort here means: do somethin= g self-contained
that brings some good and brings no harm.=C2=A0 = I think introducing
lisp-data-mode is _exactly_ in those conditio= ns.

That's not to say we can't use do _mor= e_ good as we
extend our efforts. But we shouldn't let those = ambitions
stifle the initial deed, smaller, but unquestionabl= y positive.

So I'm thinking of introducing lis= p-data-mode later on in
master, following Stefan's patch= . And using it only for `dir-locals.el`
for now (and for my = own files of course).

Is that OK with you?


--
Jo= =C3=A3o T=C3=A1vora
--0000000000008e02c605a379eb68--