How to optionally reference another package's variable
DamienCassou opened this issue · 11 comments
I feel stupid asking that as I should know the answer already but I don't (or I forgot).
I'm writing a package which makes an /optional/ reference to a variable from another, non Emacs-core, package. I protected the use of the variable within a bound-and-true-p but the byte compiler warns me that the variable is free. I would like to pacify it and tell it it's fine. Do you know how I can declare the external variable without having package-lint complain that the name of the variable should start with the current package name?
Hello,
According to my experiences, adding a defvar form without the default value would suffice:
(defvar package-variable)It must be declared before the function that uses the variable.
Yes, that should indeed pass package-lint's checks. Ideally such forward declarations are extremely rare: better where possible to have more granular packages with explicit dependencies and proper use of require.
package-lint complain that the name of the variable should start with the current package name
AFAIK package-lint doesn't complain about variable names. It's a restriction about function names.
AFAIK package-lint doesn't complain about variable names. It's a restriction about function names.
Interesting. That seems like an oversight.
I added tests for that case and it looks like everything is already working as I would have wanted: see 30258f5
So, does it throw an error about the prefix if and only if the variable has an initial value?
So, does it throw an error about the prefix if and only if the variable has an initial value?
Yep.
Oops, looks like I'm mistaken and I've pushed a failing test. I've got a cold so my brain is not at 100%.
I've commented that one out for now.
According to my experiences, adding a defvar form without the default value would suffice
thank you!
Ideally such forward declarations are extremely rare: better where possible to have more granular packages with explicit dependencies and proper use of require.
I completely agree. I think that the beginend package is an exception to this rule though: it improves navigation of many modes and requires just a few lines for each supported one.
I worked around the package-lint issue by adding a function to the external package through a PR. This is nicer than accessing private variables and functions anyway.