-
Notifications
You must be signed in to change notification settings - Fork 48
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
Radian advices on forge #540
Comments
Oh, erm. It's been a while since I set this up. What I was trying to avoid was forcing EmacSQL to be compiled just for magit-status to be opened. I guess I didn't realize that there were other entry points to Forge other than the dispatch key. Maybe ideally it would check if EmacSQL has been compiled already, and go ahead and load it if so, and otherwise delay it until the user tries to interact with a Forge feature? |
I guess the point is that the variable Also, I am not sure that such hack is necessary at all. The compilation of the binary seems to be in If you want to avoid auto-compilation of the binary in Also, in emacs 29 and later, the connection |
Radian has some advices that prevent the sqlite binary from being built when forge is loaded. Instead, delaying this to when
forge-dispatch
gets called.The problem is that it also prevents the loading of the package
emacsql-sqlite
untilforge-dispatch
is called (even if the binary is already built), which breaks forge until then, e.g., issues are not displayed and any calls to forge fail.One simple solution would be to require
emacsql-sqlite
instead of conditioning on it being loaded inradian--forge-get-repository-lazily
, but I am wondering if there is a reason that this wasn't done in the first place.The text was updated successfully, but these errors were encountered: