Re: Emacs Lisp Linter fail to identify function defined in a "use-packag

Re: Emacs Lisp Linter fail to identify function defined in a "use-packag

[Kiong-Gē Liāu]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

Hi, 

 I did some further test and found that the "function *** is not known
to be defined" error only happen once for either a undefined function
or a function defined in a nested structure, as seen in the attached
screenshot. 

1. The kkl0-fun, which is defined at top-level, linter shows no error 
   at all
2. The kkl1-fun is defined as *kk0l* global variable is assigned as t
3. The first linter error appears when the kkl1-fun is called first
time
4. At the second call-site of kkl1-fun, the linter "undefined-function"
error disappears 
5. the kkl2-fun is totally undefined, and linter identifies the
undefined function error at the first call-site
6. at the second call-site of kkl2-fun, the undefined-function linter
error disappears as well

So, it seems that elint starts to ignore undefined function starting
second call-site regardless that function is defined or not. we need
some further investigation on elint.el's elint-update-env function and
related functions. 

Thanks, 
Kiong-Gē. 

[-- Attachment #2: Screenshot from 2023-10-11 08-56-48.png --]
[-- Type: image/png, Size: 49918 bytes --]

Re: Emacs Lisp Linter fail to identify function defined in a "use-packag

[Emanuel Berg]

Kiong-Gē Liāu wrote:

> I did some further test and found that the "function *** is
> not known to be defined" error only happen once for either
> a undefined function or a function defined in a nested
> structure, as seen in the attached screenshot.

I love the enthusiasm but I think one should just byte-compile
Elisp and use that as the de facto linter, then get away with
the warnings as a way of improving the quality of the code,
and thus have better as well as faster code as a result.

If one needs/wants faster code still go
--with-native-compilation=aot. Building Emacs like that takes
some time but after that it is super fast and the little
disruption that happened with the on-the-fly/just-in-time
native compilation also don't occur.

The only thing I wonder about is, if one does that, when
byte-compiling one's own Elisp, maybe one has to explicitely
native-compile it as well? If so, it can be done like this,
for each .elc file.

	$(emacs) -Q \
            --batch \
	         --eval "(setq load-path (append load-path '($(packs)))))" \
	         --eval "(native-compile \"$<\")"

-- 
underground experts united
https://dataswamp.org/~incal