Integration support code maintainability

[jorgebef]

After using this theme for some time with quite a few tweaks and a couple of PR's merged, I would like to propose breaking the integrations down into different files under the integrations folder.
The main reasons would be maintainability as future plugins can be added just by adding a new file and adding the corresponding field to the config file and low barrier to entry for new PR's merging for new plugins that might arise in the future.

As an example, 2 of the most popular colorschemes (Catppuccin & Tokyonight) both implement it this way.

Additionally, I believe implementing types into the codebase would be great for ease of configuration as well as future development. Again, I refer to the most popular colorschemes to copy what they have done structure-wise:
https://github.com/catppuccin/nvim/blob/main/lua/catppuccin/types.lua

I am more than happy to make a PR with the proposed changes and continue discussion over there.
Thank you!

[AlexvZyl]

This is actually quite funny for me. A few years ago tokyonight did not do it this way (had everything in one file) and we had everything in separate files. Ended up moving everything into one file to follow tokyonight's example and some other reasons.

Either way, happy with @5-pebbles and @DOD-101 making the call on this one.

[AlexvZyl]

FWIW, having everything in one file should reduce loading times. Some people are very pedantic about their milliseconds.

[jorgebef]

Oh I was not aware of this at all!
Taking this into account, my proposal is based on more subjective reasons such as ease of maintenance, whereas milliseconds (even though most of the time not perceivable) are purely objective measurements.

Happy to help either way!

[AlexvZyl]

To be clear, I have not measured it. Just my intuition.

[DOD-101]

After doing some minimal testing, I am completely in favor of this.

Even at, 10000 (yes, ten thousand) files being loaded and the return values being inserted into a table the theme still loads in sub 500ms.

To be fair I have a pretty beefy setup (and an SSD), which not everyone does, but seeing as catppuccin only has 69 Integrations. I really don't think this is an issue. (at least not in our lifetimes lol)

The argument of maintainability and readability far out ways any (mostly theoretical) performance implications.

[jorgebef]

I'm happy we all agree!

I'll submit a PR adding support for a couple of plugins that I use that are currently not supported and attempt a rewrite of the integration implementation to extract it into individual files.

[AlexvZyl]

Wait, sub 500ms is actually really bad. My entire neovim config loads in ~36ms. We should test the loading time with more realistic values.

[DOD-101]

I should clarify. That time is until I can see the theme applied to nvim. Not the loading time. And that is measured more off of feel than anything else.

If we are looking at loading time in Lazy, that didn't change, since I was only requireing the files at the time when I was loading applying the colorscheme.

So now, looking at the time it takes to apply the colorscheme. Assuming the relation of files loaded to time taken is linear (which it should be) and assuming that previously it took roughly 100ms (?) to apply the theme, it would add 0.04ms per file. Which is not noticeable.

And mostly likely still far less than that, since my reaction time isn't instant.

---

Perhaps I shouldn't have named any specific values regarding time.

I was more generally trying to say that it takes 10k files to even notice any sort of difference in the time the theme takes to apply.

[AlexvZyl]

"Assuming the relation of files loaded to time taken is linear" - this will only be true if the datastructure used to store the data is pre allocated, which we can do.

Either way, should be fine. I just like numbers and performance :) It is my day-job after all.