How to optionally reference another package's variable

[Damien Cassou]

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?

[Akira Komamura]

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.

[Steve Purcell]

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.

[Akira Komamura]

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.

[Steve Purcell]

AFAIK package-lint doesn't complain about variable names. It's a restriction about function names.

Interesting. That seems like an oversight.

[Steve Purcell]

I added tests for that case and it looks like everything is already working as I would have wanted: see 30258f5

[Akira Komamura]

So, does it throw an error about the prefix if and only if the variable has an initial value?

[Steve Purcell]

So, does it throw an error about the prefix if and only if the variable has an initial value?

Yep.

[Steve Purcell]

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%.

[Steve Purcell]

I've commented that one out for now.

[Akira Komamura]

@purcell Got it, thanks.

[Damien Cassou]

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.