Problem of adding configurations in packer package declarations

[caligian]

Packer is really a counterpart of use-package o' emacs but there is one really annoying bug (not really a bug but a constraint of lua's string.dump) is that it cannot handle any variables outside of its scope (except globals baked into _G). This is extremely annoying from a configuration point of view because of verbosity that occurs due to repeatedly typing long module names. Obviously a local variable can hold the long module's declaration but I cannot imagine repeatedly declaring a local variable in every package configuration that is supplied with packer key "config".

One way to address this is giving each module its own file for configuration but again, if any non-global variable is declared in the config file, it will become nil after getting registered to key "config" of the package declaration provided to packer. This is really an annoying hassle and a source of potentially surreptitious bugs that cannot be tracked down if this limitation of packer is not known. Thankfully the default configs are wrapped in an omnifunc that is returned in entirety.

I believe that this project will obviously be evolving and more contributors will join the fray to tackle the increasing complexities of this framework and it is hard to say if all the contributors involved prefer the approach that is currently being used for configuration. I personally do not like omnifunctions because I am traditional about such things - declaring local vars and functions and then returning an init function with the required declarations to get the whole config up and running.

This is a stylistic restraint if the current approach is continued to be used. Not really a problem until some contributor pushes to the repo using a different style configuring and cause weird untraceable bugs.

One solution would be to init packer without any configuration and keeping it entirely separate of packer's starting in nvim and requiring the configs only after all the packages are loaded. I don't think should cause any additional overhead because a config provided with packer will also take a similar amount of time to eval the config.

How do we achieve this? I suggest that we should use this approach a timer/infinite-loop which checks if a certain package is loaded and then requiring the config. This is very similar to traditional configuring but without the problem of loading configs before packer lazy-loads the package.

Another thing - many packages will be lazy-loaded due to a pending keybinding which is to be pressed by the user or some filetype and similar lazy-loading technique. In this case, the infinite loop will never exit so, logically, an async timer function can check if a certain package is loaded and then require the config.

This is obviously easier said than done and I am aware that I am talking about a non-issue here but I feel that you can give it some consideration for posterity.