From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Augusto Stoffel Newsgroups: gmane.emacs.bugs Subject: bug#57884: [PATCH] Flymake backend using the shellcheck program Date: Sun, 18 Sep 2022 15:30:58 +0200 Message-ID: <87edw8n71p.fsf@gmail.com> References: <87a66yaqwc.fsf@gmail.com> <83bkre0w4m.fsf@gnu.org> <871qs9c3er.fsf@gmail.com> <87zgewdhhd.fsf@posteo.net> <87fsgoyi0l.fsf@gmail.com> <87sfko4zjq.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16336"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Eli Zaretskii , 57884@debbugs.gnu.org, Stefan Kangas To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 18 15:32:15 2022 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 1oZuP8-00046V-TP for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Sep 2022 15:32:14 +0200 Original-Received: from localhost ([::1]:56304 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oZuP7-0005vU-Mg for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Sep 2022 09:32:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33688) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZuOw-0005vM-E3 for bug-gnu-emacs@gnu.org; Sun, 18 Sep 2022 09:32:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49311) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oZuOv-0001ag-VC for bug-gnu-emacs@gnu.org; Sun, 18 Sep 2022 09:32:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oZuOv-0001ej-KF for bug-gnu-emacs@gnu.org; Sun, 18 Sep 2022 09:32:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Augusto Stoffel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 18 Sep 2022 13:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57884 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 57884-submit@debbugs.gnu.org id=B57884.16635078706303 (code B ref 57884); Sun, 18 Sep 2022 13:32:01 +0000 Original-Received: (at 57884) by debbugs.gnu.org; 18 Sep 2022 13:31:10 +0000 Original-Received: from localhost ([127.0.0.1]:48389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZuO5-0001da-Hi for submit@debbugs.gnu.org; Sun, 18 Sep 2022 09:31:10 -0400 Original-Received: from mail-ej1-f50.google.com ([209.85.218.50]:34402) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZuO2-0001dF-3R for 57884@debbugs.gnu.org; Sun, 18 Sep 2022 09:31:08 -0400 Original-Received: by mail-ej1-f50.google.com with SMTP id y3so58968869ejc.1 for <57884@debbugs.gnu.org>; Sun, 18 Sep 2022 06:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date; bh=dJSbpYtCYRsIripM63idmdy0q4kY9XKf9TlRZOeni24=; b=Ys4c9di+BTYuJvnI9ISM6rEkyx7zbRmWZ4XkGOGBM0f+6/uxylPC61n+zILkIS98qO xB9IR7YaZYATEjU4FpuKHLcTQ9xKGl7yKDRHOKB6uUccRhMPO0sg5JtkA5d9mlgzfmOO kB+HhtQNmPS37LRV0IRo9JWe7hGhFituLZSBqGsApEDcpCLvbVN/ZLWFBBhoQSfxijk9 BX5GnsdW6iNcc57LLxo42kYcQeyB4WbWUvyYNYSopqwYBp73TNNAg4AmKKlSoMv/eJSX 05SDtpiKrmYyCPghcPPBglBrsPVURDPX+5ivOOAK6NaNk5wWMz78Is6zHR3aGYeNs9L0 muEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date; bh=dJSbpYtCYRsIripM63idmdy0q4kY9XKf9TlRZOeni24=; b=7AlwguFw0doceJExEua8H1dFR8cxI4PCWZjBwDvlQKiIeS7BSOT7iqzP9YKEkkCepa A6SuZxzonBnmxgRM8YT112bC7TppXhWIy5hWwL8S9jD+VtFJE67QzUVc5HbA/NjUXaxQ Z8x+2RBBQxtmgQYj/M7FUD4dXd+F8X7ChG1IH+luyicszN7YnQfy11WBYpVva6GxVcFD laFln8eJk1ErG6Vw6lm2Bvw852RBfJnFBAlWsaGz2uQVAfT2Vqq1rtQWgQ5vtpA/kcwu 5deQsYShPFlE+SPuqUoZnIZ9d/9QYTI12Z5TsSsE6vo8XxUUOne67QJaKvz5mGXR/IGC CQHQ== X-Gm-Message-State: ACrzQf3D7bOxQzcSVpk7Kklm8DO6j6x0YN0RZr1QfrSLrPVAbshYFLPo r7sAPqdiDx3w3P1MchsK478= X-Google-Smtp-Source: AMsMyM7hd2UV9weryClAa7/Mws0gVxFwxGD29LYNtBcYbBwkUGIopK2/NJBIcu8GC5ADtjlMSTwXrg== X-Received: by 2002:a17:907:3ea8:b0:77e:f9a2:6fcf with SMTP id hs40-20020a1709073ea800b0077ef9a26fcfmr9711851ejc.701.1663507860107; Sun, 18 Sep 2022 06:31:00 -0700 (PDT) Original-Received: from ars3 ([2a02:8109:8ac0:56d0::8510]) by smtp.gmail.com with ESMTPSA id 16-20020a170906301000b007306a4ecc9dsm14062527ejz.18.2022.09.18.06.30.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Sep 2022 06:30:59 -0700 (PDT) In-Reply-To: <87sfko4zjq.fsf@posteo.net> (Philip Kaludercic's message of "Sun, 18 Sep 2022 12:50:17 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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:242992 Archived-At: On Sun, 18 Sep 2022 at 12:50, Philip Kaludercic wrote: >>> I don't use `named-let' that much, but calling both the result and the >>> recursive function `dialect' seems confusing to me. >>> >> >> Welcome to Lisp-2... > > It is not so much that they share the same name, but that I don't > understand why you close to give the function the name "dialect". From > what I have seen, named-let is usually given a self-referential call > like "next", "recur", "loop", etc. Yeah, I have no strong opinion about the name. >>> Wouldn't it be cleaner to pull this lambda out into a separate named function? >>> >> >> That's not possible, it needs to be in that lexical scope. > > Not if you use `process-put' and `process-get'. I recently reworked > flymake-proselint and did the same thing. IMO it doesn't look that bad: > > https://git.sr.ht/~manuel-uberti/flymake-proselint/commit/30c4baa08db32e73d956c978c81a9f79062c2e1d Honestly, I much prefer to have some state localized in a closure than in what is effective a global variable... I like in your backend that you read a JSON output, which presumably provides the start _and end_ of the diagnostic region. How did you convert from line/column to buffer position? I think it would be nice to extend flymake-diag-region to have signature (flymake-diag-region BUFFER LINE &optional COL LINE-END COL-END) If you provide LINE-END and COL-END, then those are converted to buffer positions and there's no guessing as to what they should be. >>> Also what happens if someone doesn't have shellcheck installed? >> >> Then Flymake logs a warning and disables the backend. The error message >> will be whatever make-process gives, which I find more than good enough. > > But isn't that rather late to detect the error. Couldn't you also check > if "shellcheck" (or whatever the new option name will be) can be found > in the path before adding the hook in `shell-mode'? I think this is worse than not doing anything. If you don't check and let the backend fail, it gets displayed as a disabled backend, and the user has the chance to look at the log buffer and try to figure out why it's not working. If we did what we suggest, we'd have to reinvent the wheel to convey that information to the user, I think.