selectrum with use-package (compiler warning)

[jsirex]

(setq package-quickstart t)
...

(use-package selectrum
  :init
  (selectrum-mode +1))

Macro expanded to

(progn
  (use-package-ensure-elpa 'selectrum
                           '(t)
                           'nil)
  (selectrum-mode 1))

During compilation I got:

init.el:607:1: Warning: the function ‘selectrum-mode’ might not be defined at runtime.

It does not work until I re-active it by off-on mode. I checked that autoload is present

GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) of 2021-01-22, unofficial emacs-snapshot build: http://emacs.secretsauce.net

[clemera]

Thanks! You meant during compilation of your init file? I think compiling your init file is generally discouraged, selectrum-mode is defined within the autoload file itself to allow enabling it without requiring to load the selectrum file itself.

[jsirex]

I fixed off-on mode issue by removing emacs-desktop and starting from scratch. However, warning is still here

[clemera]

If you want to keep compiling your init file (I wouldn't recommend it) and want to get rid of the warning you could probably add a (declare-function selectrum-mode "selectrum" nil t) to avoid it.

[minad]

@clemera

I think compiling your init file is generally discouraged

If you want to keep compiling your init file (I wouldn't recommend it)

I disagree ;) If you have heavy macro expansion in your init.el it is worth it. Furthermore I am using a heap dump, at this point it starts to matter.

@jsirex

This warning is mostly harmless but can be worked around by defining :function in use-package as far as I know, or use declare-function as @clemera proposed. But I have multiple of these warnings when compiling my init.el and it is not an issue.

[minad]

There is one more thing about compilation I think - if you evaluate lambdas the interpreter does not perform a proper lexical closure analysis it seems and creates monster closures. I had this issue when debugging consult--read and evaluating it. The bytecode compiler in contrast gets this right. Therefore the more you compile the better ;)

[clemera]

I guess it depends how you organize your config, I have to add that I put any "real code" outside the init file and compile those files, too.

[minad]

Okay, sure that is a valid approach too. I also straced emacs startup for the fun of it (it is horrible btw) and it only loads the init.elc and nothing else in my case. But my config is more of a mess than yours I think. I rather try to move real code to real packages and avoid creating multiple config-xyz.el files as is very common in many popular configurations.

[jsirex]

I'm using single init.el with sorted use-package macro. I'm also using packages quickstart feature. It merges all autoloads in one file and compiles them.

(use-package selectrum
  :functions 'selectrum-mode
  :init
  (selectrum-mode +1))

This also does not help. I tried to regenerate package-quickstart.el and have noticed another warning:

package-quickstart.el:2250:2170: Warning: defcustom for ‘selectrum-mode’ fails
    to specify containing group

[clemera]

This also does not help. I tried to regenerate package-quickstart.el and have noticed another warning:

Thanks, I added the group in e930b10326a53b1bbf4c57a42b01d954f5555ceb. I missed that because for defcustom specified in the same file as defgroup you don't need it at all.

[raxod502]

I think compiling your init file is generally discouraged

Just to throw in my two cents to this discussion, the bulk of my configuration is in a separate file and byte-compiled, and my init.el is mostly a wrapper to add error handling as well as automatically detect when the main config file .elc is outdated, and prevent it from being loaded in that case.

Here is the code for that: https://github.com/raxod502/radian/blob/193c702c810562c770a0e09d787eb9bd3d93cda2/emacs/init.el#L82-L115