From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Flymake refactored Date: Sun, 01 Oct 2017 23:12:49 -0400 Message-ID: References: <87h8vmj3tr.fsf@lolita> <87y3oygxqb.fsf@lolita> <87infyizeg.fsf@lolita> <87mv5agy74.fsf@lolita> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1506914014 24496 195.159.176.226 (2 Oct 2017 03:13:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 2 Oct 2017 03:13:34 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: joaotavora@gmail.com (=?windows-1252?B?Sm/jbyBU4XZvcmE=?=) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 02 05:13:30 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dyrAg-00060p-3A for ged-emacs-devel@m.gmane.org; Mon, 02 Oct 2017 05:13:30 +0200 Original-Received: from localhost ([::1]:50438 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dyrAn-0004ND-6x for ged-emacs-devel@m.gmane.org; Sun, 01 Oct 2017 23:13:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dyrA6-0004N8-3d for emacs-devel@gnu.org; Sun, 01 Oct 2017 23:12:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dyrA2-0006Zi-TC for emacs-devel@gnu.org; Sun, 01 Oct 2017 23:12:54 -0400 Original-Received: from pmta11.teksavvy.com ([76.10.157.34]:55810) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1dyrA2-0006Z9-NO for emacs-devel@gnu.org; Sun, 01 Oct 2017 23:12:50 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EHDwClrdFZ/1V13mhbHAEBBAEBCgEBg?= =?us-ascii?q?11EgQ6DVYVYhgaObQGBdS8BmA4KhTUEAgKEMlgBAgEBAQEBAgNoKIUZAQQBViM?= =?us-ascii?q?FCws0EhQYDVKKDQinTYsxAQEBBwImgy2IZYRehhoFoTKgMYc9lVSBOViBDjIhC?= =?us-ascii?q?DJJhzkkhzCCQgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2EHDwClrdFZ/1V13mhbHAEBBAEBCgEBg11EgQ6DVYVYhga?= =?us-ascii?q?ObQGBdS8BmA4KhTUEAgKEMlgBAgEBAQEBAgNoKIUZAQQBViMFCws0EhQYDVKKD?= =?us-ascii?q?QinTYsxAQEBBwImgy2IZYRehhoFoTKgMYc9lVSBOViBDjIhCDJJhzkkhzCCQgE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.42,467,1500955200"; d="scan'208";a="5493714" Original-Received: from 104-222-117-85.cpe.teksavvy.com (HELO ceviche.home) ([104.222.117.85]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Oct 2017 23:12:49 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 25D8A6627F; Sun, 1 Oct 2017 23:12:49 -0400 (EDT) In-Reply-To: <87mv5agy74.fsf@lolita> (=?windows-1252?Q?=22Jo=E3o_T=E1vora?= =?windows-1252?Q?=22's?= message of "Mon, 02 Oct 2017 02:01:19 +0100") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.34 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:218999 Archived-At: >> enough of the details to be sure, but my gut feeling tells me that it'll >> be hard to preserve the desirable properties while interfacing >> through flymake (since it's targeted at a very different use case). > I don't know (I also haven't looked at the code) but none of those > things sound like showstoppers. For a start, I'd be happy just > preserving the fact that it isn't based on regexps. The only thing a > backend has to do is tell flymake where some problems exist. Even a naive > solution like running nmxl in a subprocess emacs and prin1'int a list of > collected errors, like we do for elisp-flymake-byte-compile now, > shouldn't be horrible. Oh, I don't forsee any major difficulty in writing an nxml backend for flymake, *IF* we limit ourselves to the goal of making it work. But if we want it to work about as well as nxml-mode itself, it'll be harder. >>> Didn't do this too. If we mark it obsolete, what's the "use instead" >>> message? >> Don't know. flymake-diagnostic-functions? > Yeah, but right now that's saying "this bit is obsolete, go write a > replacement and then use that instead. good luck " I thought you were the one saying that flymake-proc is all legacy and will be replaced. I don't think anyone has claimed that flymake-proc is *currently* obsolete, just that the plan is to retire it at some point (this point being presumably after a replacement is written). > Regarding the merge to emacs-26, do you see anything else we need to > iron out before it? Maybe just this issue of letting backends tell flymake.el whey they're done (and letting flymake tell backends to abort the currently running check)? Stefan