use-package with config: function might not be available at runtime

1.1k Views Asked by At

I like using use-package for Emacs. Among other things, I have the following in my configuration file:

(use-package proced
  :ensure t
  :config
  (proced-toggle-auto-update 1)
  (general-define-key
    :keymaps 'proced-mode-map
    "j"   'next-line
    "k"   'previous-line))

Flycheck warns that the function proced-toggle-auto-update might not be available at run time. However, the documentation of use-package states that all forms following config: are evaluated after the package is loaded. Is this flycheck warning a false positive then?

2

There are 2 best solutions below

0
On BEST ANSWER

If you know the function will be available at runtime, eg. the package will have been loaded (since that function is not autoloaded), then you can let the compiler know by declaring the function, eg.

(declare-function proced-toggle-auto-update "proced")

I don't use use-package but presumably the package will have been loaded given the documentation you cite, so yes, this would be a false positive.

In other circumstances you could explicitly autoload a function as well and let the compiler know,

(autoload 'proced-toggle-auto-update "proced")

These actions assume the library "proced" is on your load-path, eg. (featurep 'proced) is non-nil.

2
On

The flycheck emacs-lisp-checker is using the byte compiler to figure out possible issues with the code, and it needs a little help to figure out things with use-package. For my init files with use-package, I do two things:

First, I define a directory local variable for my init files (in .dir-locals.el):

((emacs-lisp-mode . ((flycheck-emacs-lisp-load-path . inherit))))

With inherit set, the load-path used by flycheck is taken from the current load-path, so it can find all the files in various lisp packages.

Second, I have (require 'use-package) in each of the separate files in my init. This seems redundant, but it lets flycheck check the files individually, because it can expand the use-package macro for better analysis.

This setup seems to avoid most of the warnings coming from use-package, except for ones that really matter. It's not tested on your specific configuration, however.