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: Fri, 13 Oct 2023 03:47:59 +0200 Message-ID: <87wmvr70og.fsf@dataswamp.org> References: <87il7c8le4.fsf@dataswamp.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35802"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:c2va4DkkgQXL9M3sqYvPRHol5/8= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 13 07:31:19 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 1qrAlb-00098I-0w for ged-emacs-devel@m.gmane-mx.org; Fri, 13 Oct 2023 07:31:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qrAkq-0002ow-JZ; Fri, 13 Oct 2023 01:30:33 -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 1qr7Hh-0005Q9-S9 for emacs-devel@gnu.org; Thu, 12 Oct 2023 21:48:13 -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 1qr7Hg-0000fc-75 for emacs-devel@gnu.org; Thu, 12 Oct 2023 21:48:13 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qr7Hb-0008x6-Q5 for emacs-devel@gnu.org; Fri, 13 Oct 2023 03:48:07 +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: Fri, 13 Oct 2023 01:30:30 -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:311421 Archived-At: > Well, here the discussion can go both ways! Because in a way > it makes sense that every file `provide' its stuff, and > every other file that wants to use it `require' it. Yes, this is a huge problem if you want to tidy up one's Elisp using elint. You get so many warnings this or that variable isn't known to be defined, you check where it is defined but that source file isn't `provide'd or in some cases (e.g. `float-pi') it is incorrectly provided (i.e. it is defined in float-sup.el but that file provides its services as "lisp-float-type"). Note that this isn't elint's fault, on the contrary, the fault is with those files. But what happens is the interesting situation that one cannot use elint to tidy up one's Elisp, because the Elisp of vanilla Emacs isn't tidy enough. Not good! Yeah, all files should `require' everything they need and provide itself in the end. This situation in itself isn't optimal - well, as we have just seen, it is error prone - since it can and should be automated, there is no need to rely on humans to do this work, however now it isn't and that means one must get it right manually. > Update 1, elint is correctly seeing defuns in lexical > let-closures, and there is no need to use `declare-function' > for it do that as was incorrectly theorized the day before. > This is interesting because the byte-compiler does not see > those so there declare-function is needed. Unfortunately, this isn't exactly true either. Both elint and the byte-compiler are silent if a defun in a lexical let-closure is just defined. However if and where it is _used_, elint cannot see it, and `define-function' doesn't help. define-function does shut up the byte-compiler in this situation tho. -- underground experts united https://dataswamp.org/~incal