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: Three Flymake backends Was Re: Two issues with the new Flymake Date: Sat, 04 Nov 2017 11:30:25 -0400 Message-ID: References: <87k1z7adxi.fsf@metapensiero.it> <87po8zrubl.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1509809487 5360 195.159.176.226 (4 Nov 2017 15:31:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Nov 2017 15:31:27 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 04 16:31:23 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 1eB0Pr-0001CS-9k for ged-emacs-devel@m.gmane.org; Sat, 04 Nov 2017 16:31:23 +0100 Original-Received: from localhost ([::1]:41321 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eB0Py-0003PN-K1 for ged-emacs-devel@m.gmane.org; Sat, 04 Nov 2017 11:31:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48289) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eB0PK-0003P2-Oo for emacs-devel@gnu.org; Sat, 04 Nov 2017 11:30:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eB0PH-0007SL-Ko for emacs-devel@gnu.org; Sat, 04 Nov 2017 11:30:50 -0400 Original-Received: from [195.159.176.226] (port=44126 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eB0PH-0007Rw-DF for emacs-devel@gnu.org; Sat, 04 Nov 2017 11:30:47 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eB0Oy-0006Fp-SZ for emacs-devel@gnu.org; Sat, 04 Nov 2017 16:30:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 80 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:MM/AJPIeilqim+uS97zHWO9aki0= 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:219923 Archived-At: FWIW, I think we can install those backends into emacs-26, and later consolidate them in `master`. > Obviously, this makes maintenance hard if small fixes are made to the > common structure. The tex-chktex backend recently contributed by Mark is > already an example of that in that it is missing a fix that this type of > backend requires (I pushed a fix in the meantime). > > So I'm thinking that, for master (_not_ emacs-26) we could use a > declarative flymake-define-simple-backend macro. FWIW, I think that "makes maintenance hard if small fixes are made to the common structure" is also an argument against the use of a macro (or at least against putting the common structure in the macro's expansion), since it would imply that you need to recompile the backend in order to benefit from fixes in the common structure. Also using a macro like you did makes it difficult to debug/edebug the common code. Better move that common code into a function. See additional comments about the code below, Stefan > (defvar-local flymake--simple-backend-procs > (make-hash-table)) You never `setq` this var, so it will behave like a global var. More specifically, a single hash-table is used for all buffers, which I believe is not what you intended. > (defmacro flymake-define-simple-backend (name command pattern &optional type-predicate) > "Define a simple Flymake backend under NAME. I had to look at the code to understand what you meant by "under NAME". I'd have written it more like "Define Flymake backend function named NAME", maybe. > PATTERN must evaluate to a list of the form (REGEXP LINE COLUMN > TYPE MESSAGE): if REGEXP matches, the LINE'th subexpression gives > the line number, the COLUMN'th subexpression gives the column > number on that line, the TYPE'th subexpression gives the type of > the message and the MESSAGE'th gives the message text itself. Line numbers are reasonably standardized, but column numbers aren't. Some tools start counting from 0 others from 1, some count bytes, others count chars, yet others count actual "visual" columns. `compile.el` has added some vars to control this, but it's rather messy. So we should make it possible to provide code which does the conversion to whatever we use. Maybe it would also make sense to try and support message which include both the BEG and the END. Rather than `type-predicate`, I'd rather just allow `type` to be a function. Also it'd probably make sense to allow the type returned by that function to be nil in which case we should just skip the match (i.e. not create a diagnostic for it). So I guess I'm looking at something that look like a `flymake-simple-backend` with signature: (flymake-simple-backend COMMAND REGEXP MSG TYPE START &optional END) where MSG and TYPE are normally integers, and START and END can be either an integer (line-number submatch) or a list of 2 integers (LINE COL), and all 4 of those could be functions instead. > (let ((name-once name)) I must say I don't get what this -once business is about. What is `-once` supposed to mean? What did you need it for? > + (add-hook 'flymake-diagnostic-functions 'perl-flymake nil t)) ^^ #' -- Stefan