This repository has been archived by the owner on Apr 16, 2024. It is now read-only.
Replies: 1 comment
-
This is above my own knowledge but I just wanted to let you know that I have read it. However, I "think" that I like what I am reading :P |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Obviously the easiest way is to reload the init.lua but that may be inefficient because we might include init code which we may not prefer to re-eval after adding a new package.
Thankfully packer can be init and used to append to the current package list multiple times as long as packer.reset() is not declared anywhere. This should allow us to add functionality to load packages post-doom-initialization. I think many users will be happy with this as they can temporary test out new plugins from any buffer and not mess with the core functionality of doom.
However, this approach can become annoying for the users as packer at every reload or startup will ask the user to delete the repos of the previously tested repos as packer will see no declaration in its main list but discover a downloaded repo at site/pack/packer/(start|opt) and trigger PackerClean automatically. So we can simply provide a function that git clones into site/pack/testing and packadd that package and delete it by hooking a delete command to VimLeave using autocmd.
That was some digression. I apologize for that.
Getting back to the moot.
One of the reloading mechanisms can be to maintain a md5 hash table of supplied configs which can be checked for any file changes and only selectively load packages whose configs have changed. We can store this md5 hash table in a file so that it won't be created every time doom starts and increase the startup time. Lastly, in order to determine new or absent packages, we can hash the md5 hash table file itself and check if it has changed. If it has changed then we can use table.maxn to determine the number of changes and obtain those packages by checking which keys are absent or added.
This should solve the problem of unnecessarily executing one-shot init code and reload configs that are actually new. This can prevent potentially untraceable bugs. I say this after experiencing the headache caused by SPC hrr in doom-emacs
Beta Was this translation helpful? Give feedback.
All reactions