Refactor: decrease cost of requiring main module

[wbthomason]

This PR reorganizes part of the main packer module to (1) defer the cost of managing each plugin until an operation is required, and (2) defer requiring and configuring the modules that implement the actual functionality of packer. Together, this lowers the cost of requiring the main packer module and adding plugin specifications from ~4ms to ~0.2ms on my setup.

The motivation for this is as stage 1 of moving toward automatic compilation and some other major QoL improvements. By making it close to zero-cost to require packer, we make it practical to ask users to run startup or equivalent in their init.lua files, which will make it easier to implement operations like auto-recompilation and hopefully using config/setup functions directly i.e. without the loadstring dance and its restrictions.

@akinsho: I've done some manual testing of this PR, enough to think it probably doesn't break anything. However, I'd appreciate a second set of eyes (or more if anyone else is willing) - there's a decent probability that this breaks some module by forgetting to configure it before it's used (previously, all modules were configured in the init function).

[wbthomason]

Hmm, looks like this interacts with the CI tests in an unexpected way; I'll have to take a look to see why those failed.

EDIT: We can ignore the test failures for the moment, but the tests should be updated as part of this PR. The failures are happening because the current tests don't trigger the deferred management of plugin specifications that this PR adds.

[akinsho]

This looks good @wbthomason excited to see the automatic recompilation land. I'll test this out later on today

[akinsho]

@wbthomason just tried this out, profile and status seem to work fine although when I run PackerSync for the first time after starting nvim I initially get a

[packer.nvim] [ERROR 14:25:14] async.lua:20: Error in coroutine: ...are/nvim/site/pack/packer/opt/packer.nvim/lua/packer.lua:450: attempt to index local 'display_win' (a nil
value)

error and then subsequent attempts to run the command work fine.

[wbthomason]

@akinsho I've fixed the issue with PackerSync. I'd previously just tested with install/update/compile/clean separately; the problem was that I was invoking the deferred plugin management function after gathering the set of plugins to sync, meaning that it was empty.

This does expose that we should add some early-exit logic for an empty plugin set, though.

[akinsho]

@wbthomason just tested this again and it seems to work fine.

[nanotee]

Seems to work fine on my machine as well, and requiring the main packer module is much faster: ~13ms on the master branch vs. ~3ms with this PR.

[wbthomason]

Thanks for trying this out! I think this is ready to merge once I fix the tests.

[shadmansaleh]

The motivation for this is as stage 1 of moving toward automatic compilation and some other major QoL improvements

I'm not sure it goes here or not .
But is there anyway to make error messages less cryptic ? I think compilation adds a ton of complexity for little gain for packer . Also those errors are mainly so cryptic because functions are loaded with string.dump and packer_compiled has bunch of lua blocks in a vimL file .

Though it's probably going to be a big refractor I think everyone will have a lot less headache for everyone at the end if packer just loaded the configuration directly instead of compiling it .

Ok . I just had to say it . I've been banging my head on packers config for over an hour because I have mistakenly used :source and a lua file instead of :luafile in a config function [And basically had no way to understand even where the error was occuring :( ]
Entire nvim was broken because packer won't even load other plugins because of error in this plugins config.

@wbthomason can you at least please take a look at #343 with that at least other plugins wont be affected when error occurs in a plugin .

Pardon me if I sound rough I'm just really frustrated right now .

[wbthomason]

@shadmansaleh This PR is actually part of a move away from using string.dump. By making it cheap to require packer, we're going to make a shift toward expecting users to load their packer config in their init file, which means that we can use plain old functions for config and setup and reduce the compiled file to just be things like precomputed paths to source, setting up lazy-load hooks, etc. I definitely get your frustration here; the fragility of the current approach is an embarrassing sharp edge for packer and has been for a while.

I'll take a look at #343; it slipped off my radar. Sorry that I haven't had a lot of time for packer lately!

[shadmansaleh]

I'll take a look at #343; it slipped off my radar. Sorry that I haven't had a lot of time for packer lately!

No problem . Everyone has their lives :)

[wbthomason]

Fixed the tests and removed the unnecessary merge commit, so I think this is good to go.