Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sharp-quoting in use-package's :general-config keyword warns that function may not be defined at runtime #564

Open
arifer612 opened this issue Jul 11, 2024 · 0 comments

Comments

@arifer612
Copy link

arifer612 commented Jul 11, 2024

Describing the Issue and its Fixes

Using sharp-quoted functions with the :general-config keyword in a use-package declaration, flycheck raises warnings on some functions for possibly not being defined at runtime.

NB: In the following text, I am using user-defined key-definers tyrant-def and despot-def. They are both defined in the same manner as in the README, with the only difference being that despot-def has an additional (:major-modes t) declared.

An example of a use-package declaration for `org-roam', with only the relevant lines of codes:
Screenshot from 2024-07-11 12-45-40

All three functions, i.e., org-roam-buffer-toggle, org-roam-alias-add, and org-roam-make-permanent, raised the same warnings about the functions possibly not being defined at runtime. The last function is a function defined within the :config keyword (not in frame).

Note that the issue is also present in despot-def, which is made clear when the lines with warnings in tyrant-def are commented out:
image

Attempt 1 to Fix the Issue: Using the :functions keyword

My first attempt to fix the issue was to declare dummy functions with the same name, as suggested in the use-package documentation. An image of the result is as follows:
Screenshot from 2024-07-11 12-54-35

Now, only the issue with the user-defined function org-roam-make-permanent is resolved. The other two functions still remain.

Attempt 2 to Fix the Issue: Moving to the :config keyword

My next attempt was to simply push these keybindings into the :config keyword, with the hopes that the macro will be expanded in a way such as to ensure that these sharp-quoted functions are understood to be defined by the time the package actually loads. An image of the result is as follows:
image

Now, the user-defined key-definers raise warnings about not being known to be defined, whilst two other sharp-quoted functions raise warnings about possibly not being defined at runtime. The former is easily resolved by declaring dummy functions with the same name, but the latter remains even after doing so.

Attempt 3 to Fix the Issue: Using the :general keyword

My third attempt was instead, to use the :general keyword. An image of the result is as follows:
image

All is well! Sharp-quoted functions work without an issue, but I definitely do not need these keybindings to be defined before the package even loads.

I also noticed that using the :general keyword, there is no need to declare the functions in the :functions keyword as it automatically creates autoloads for these functions, as described here. An image of the result of removing the :functions keyword is as follows:
image

Attempt 4 to Fix the Issue: Removing the Sharp-quotations

My fourth attempt was to consider removing sharp quotations. This step is supposedly inconsequential since sharp-quoting a symbol that points to a function only serves to declare that the symbol points to a function. However, the result is not inconsequential in the image that follows:
image

All is well again! Removing the :functions keyword does not affect the result as well, as in the image that follows:
image

I will expand a little more about this in the next section.

Comments

Although a workaround to the warnings has been found in the fourth attempt, I would personally prefer to be able to use sharp-quotations to make it clear to myself which symbols point to functions. I also find it very curious that the action of sharp-quoting a symbol pointing to a function, which is supposedly inconsequential logically, is not idempotent when (presumably) expanded in a macro. I'm not sure where to begin to identify where the issue lies, but this is a bug that I think I have found and hope a resolution can be found for it soon, as the flycheck warnings are really not so pleasant to the eye.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant