From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp Linter fail to identify function defined in a "use-package" block Date: Wed, 11 Oct 2023 02:59:56 +0200 Message-ID: <8734yi9do3.fsf@dataswamp.org> References: <14e940300c05e0f19efd14f10610192319372808.camel@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29459"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:PlSvOzZUK1KeW0bVvYHjxSGVQRM= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 11 04:23:37 2023 Return-path: Envelope-to: ged-emacs-devel@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 1qqOsr-0007Sx-Gb for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Oct 2023 04:23:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qqOs0-0002jG-Ou; Tue, 10 Oct 2023 22:22:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qqNa6-0000qq-Eq for emacs-devel@gnu.org; Tue, 10 Oct 2023 21:00:11 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qqNa4-0005n4-Hp for emacs-devel@gnu.org; Tue, 10 Oct 2023 21:00:10 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qqNa2-0008op-TM for emacs-devel@gnu.org; Wed, 11 Oct 2023 03:00:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 10 Oct 2023 22:22:43 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311404 Archived-At: Kiong-Gē Liāu wrote: > I found that the built-in Emacs lisp linter [...] If we are talking `elint-current-buffer', I just tried it on a couple of my Elisp files. Most of them has warnings of the type Reference to unbound symbol or Setting previously unbound symbol and indeed, even running it on elint.el itself produces such warnings - but these warnings are not reported by the byte-compiler and also do not cause problems in practice. I don't know what one is supposed to do to with them, `require' even more files than the byte-compiler demands? It also reports errors like this for functions with &rest arguments, apparently the linter does think they are mandatory, Wrong number of args: (cl-remove 32 (string-to-list abc)), (ITEM SEQ [KEYWORD &rest VALUE]) Elint was written in 1997, it is likely the situation was quite different back then, maybe that is the explanation. But I think the byte compiler should be the de facto linter, instead of improving elint.el (and `checkdoc' for that matter) whatever good stuff are in those should be incorporated into the byte compiler to have all the tidying up at one place. Now we also get warnings from the native-compiler - where does it all end? In one and only one place - would be optimal for me, at least. But cred to Emacs hackers be it 1997 or 2023! -- underground experts united https://dataswamp.org/~incal