Determine if we can compile in .zshrc pre-initialization

[Eriner]

• [ ] Determine whether there would be a speed decrease when doing this.
• [ ] Determine whether we could have users just sourcing one file in .zshrc (for sake of simplicity), or if it's better to keep separated code being sourced by .zshrc and .zlogin.
• [ ] Determine whether we can make core one (1) file (again, for simplicity even during installation of zimfw).

[Eriner]

This would fix #232, #231

[ericbn]

@Eriner, I had new ideas about this. To reduce the number of times we try to zrecompile code, we could narrow down to these scenarios:

1. when the zmodules array changes by being manually edited by the user (maybe we could keep a copy of the array that was last zcompiled, or maybe we could just ignore this scenario)
2. when a module changes using the zimfw tool, either when it's installed as a new one, or when it's updated because new commits were pulled
3. when modules with existing directories but not referenced from zmodules are cleaned using the zimfw tool (maybe we can ignore this scenario if we're considering scenario 1)
4. of course, this could also be manually forced with something like zimfw cache-build

TL;DR The overall idea is to just do the recompile when the zimfw tool is used.

[PatTheMav]

@ericbn I might have a use case that isn't covered by those optimizations:

Currently I have a lot additional code for my bash and zsh environments that resides in my dot files. I have a daily routine that updates those and also updates zim itself, but also generates a new digest of all my additional code. This digest file is symlinked into the custom module.

This allows me to maintain custom zsh code independently of zimfw, but still makes it work within it. Right now recompile detects if the init.zsh changes, but wouldn't with those changes as the module setup itself never does.

[ericbn]

@PatTheMav, in this case you would have to call zimfw cache-build manually after you make changes to your custom code.

Or yeah, you have a point: people can have custom modules which code changes. And that is not covered in my list above.

Suggestions?

[PatTheMav]

@ericbn - true, I could make that part of the update process that updates zim itself anyway.

From personal experience I know how hard it is to make something fast as well as making it dynamic and reactive. The latter part will introduce overhead and code that mostly eats up the speed improvements. And the basic idea is to avoid as many file consistency checks as possible (even comparing the given zmodules array with a cached version could be undesirable).

I'll try to think about this a bit, as I don't really have a "better" option right now.