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 16:50:21 -0400 Message-ID: References: <87h8vmj3tr.fsf@lolita> <87y3oygxqb.fsf@lolita> <87infyizeg.fsf@lolita> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1506891043 25827 195.159.176.226 (1 Oct 2017 20:50:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 1 Oct 2017 20:50:43 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 01 22:50:39 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 1dylC8-0005st-Ld for ged-emacs-devel@m.gmane.org; Sun, 01 Oct 2017 22:50:36 +0200 Original-Received: from localhost ([::1]:49751 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dylCE-0001UX-H0 for ged-emacs-devel@m.gmane.org; Sun, 01 Oct 2017 16:50:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dylC8-0001UQ-1u for emacs-devel@gnu.org; Sun, 01 Oct 2017 16:50:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dylC5-00053y-4l for emacs-devel@gnu.org; Sun, 01 Oct 2017 16:50:36 -0400 Original-Received: from [195.159.176.226] (port=47754 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dylC4-000536-T8 for emacs-devel@gnu.org; Sun, 01 Oct 2017 16:50:33 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dylBu-0004pi-KL for emacs-devel@gnu.org; Sun, 01 Oct 2017 22:50:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 60 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:CYZGy8sKnXE5PiCve2ZOzP5DODk= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:218993 Archived-At: > [In the meantime I see you've been checking out emacs-diffs. Just a > heads up that deleted the scratch/flymake-refactor and repushed it again > with some different commits (but most of original tree is still > identical hash-wise) > Sorry for the git no-no. I did nothing special, just a bit obsessed with > clean Git history I guess] That's OK. We want to allow this in scratch branches. > Sorry, I mistook advice-add for add-function. I meant to say that > cl-letf is better than advice-add for dynamic localized overrides, but > you're right, it's not, as it binds the symbol globally. I fixed this. I saw your recent introduction of proper hooks for checkdoc and bytecomp. I intend to take a closer look at them, but haven't had time for it yet. >> Let's try and move the ones that were sufficiently well designed that we >> can keep using them in flymake.el without regret. For the others, they >> can definitely stay in flymake-proc.el. > I can only think of porting flymake-proc-stop-all-syntax-checks, but: > * That is hard to do generically (requires more API) > * I don't see why it's particularly useful > I'd rather fix bugs in flymake-proc.el like the one that leaves those > @#$% *_flymake.c files behind (I think this happens because the cleanup > functions are local to a buffer that is outlived by the process, BTW) "Hard to do generically + not particularly useful" qualifies as "with regret" I think ;-) >> If we want to link something like nxml's checker into flymake in a good >> way, we'll probably just need a completely different hook than >> flymake-diagnostic-functions. > Really? That's disappointing... Even with the new version of > flymake-diagnostic-functions? I don't actually know. But since nxml's checker currently doesn't go though flymake.el its design was special tailored to take advantage of the info available in Emacs (e.g. knowledge of what was changed, to avoid repeating previous checks, knowledge of what's displayed, so as to do all the checks "instantly" yet lazily, ...). I can't remember 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). > Actually, I just (require 'flymake-proc) *after* (provide 'flymake) in > flymake.el. It looks pretty clean to me, does you see any drawbacks? Yes, I saw that. It's indeed simple, and should work fine especially for a file which we plan on marking obsolete. >> I only meant to mark it as obsolete. But if the whole of flymake-proc >> is considered obsolete (or close enough), then it's not even worth it. > Didn't do this too. If we mark it obsolete, what's the "use instead" > message? Don't know. flymake-diagnostic-functions? Stefan