Functional module interface

[caligian]

As promised, I have come with a functional module interface for configuration. I have transferred the old configuration to this one and it works pretty well (for now). It might be a little buggy and packer.nvim quirks need to be followed in some places but so far, so good.

Startup time is very good. Almost feels instant as compared to my previous setup with the same exact configuration. I have tried to implement lazy-load wherever possible.

Theoretically everything can be overridden because all the settings and functions lie in a single table.

Package configurations can be overridden with ease by the user at the cost of losing all the defaults made by the system (although this can be changed. I am just not sure if I should).

New LSP setups are a matter of ease because all the user has to do is append the configuration to either doom.lsp.user_servers or doom.lsp.default_servers. If the user appends to latter, default config for that server will be used. It is mostly batteries included so little to no setup is required to setup lsp apart from actually downloading the required stuff. This works out of the box for ruby, python. However, default configurations can also be quickly installed by appending the name of the server to doom.lsp.default_servers. I have tried to include capabilities and on_attach defaults in case user only provides the path to the binary so it should work for basic cases.

I hope that we can add some nice cosmetic layers hopefully with zero overhead and provide a nice doom-like package enabling-disabling with categories locking packages to certain versions, etcetera

Some caveats:

1. Some packages are downloaded to stdpath('data')/site/pack/unmanaged because they are necessary for the defaults set by doom.
2. It is not working on windows (mostly a path conflict)
3. Telescope project throws a weird error but works
4. Init.lua needs to be rewritten

This is certainly not final but I am hoping that all of you are ready to shower critique wherever required. Since everything is dependent on the global table, it is rather easy to reload doom quickly although I believe some more functions should be added to make this easier.

There is a utils.lua file containing some important functions: autocmd and augroup maker, basic indenting, buffer-running functions for both powershell and bash. I am also going to add a native REPL module.

Updated config:
Check out core/

[LuigiPiucco]

Hi, caligian! First of all, great work! I'm reading through your repo, it looks quite good, there are many interesting things I'd like to (if you wouldn't mind) merge with my implementation. More on that at the end. Now I'll comment on the bits I like/would change:

• utils.mkautocmd and utils.hook implementations
  This is indeed better than the simple concatenation I kept from the original, you even managed to make it work for lua functions.
• utils.lua
  Just in general, this file is very well thought out.
• Use of _G for (too) many functions
  This is the first bit of criticism. _G is (at least in my view) to be used sparingly, and preferably with some kind of namespacing. The way I would prefer is to place things we don't really want to waste names for the user in a _doom global. For instance, the lua functions passed to autocmds and hooks probably aren't very useful afterwards, and if they are they also usually have a name already. So, putting them in _G._doom.autocmds would be better. The same goes for utils only we use.
• repl.lua
  While I like this, I think it's out of scope for this project to implement a repl framework. The original had something like this, and I removed it in my implementation, in favor of adding it later with a proper package for repls (if it doesn't exist yet, we can implement it, just not inside doom). I think doom should configure an existing repl framework. This also sounds like something that could be extended into nvim-dap or nvim-dap-ui.
• packages.lua
  It would be good to group these by module, such that you can batch disable related packages by commenting out the relevant module from a config file. Correct me if I'm wrong, but to disable something here, I'd need to do table.insert(doom.pkg.disabled, "repo/url") for each unwanted package, which is a lot more than just toggling a line. Also, if I want to use a fork, because these are indexed by repo url, not package name, defaults would break, given that configs in package_config.lua wouldn't apply to the fork due to the different key. This could be fixed with some regular expressions as well, but that's just over complicating things.

Now about merging your code: I really like the utilities you came up with, and I'd also like to have your name properly in the commit history, so maybe we could coordinate something over discord? (the link to doom's is in the README)

If you don't care about this or don't have the time to contribute to my implementation, I can do it myself, and probably will be doing so until you answer. Just tell me if you'd like to contribute to my repo or not.

[caligian]

Hi, thank you for your time. I would definitely like to contribute to your repo. You can borrow anything from my config. Given our differences regarding package configuration, I would like to maintain my own repo and not coerce you into doing anything that goes against the collective philosophy of devs contributing here. However, I can add a functionality that respects your repo's style and mine. If I end up putting it, you can further tell me what to do to make it respect the current implementation, I'll try to make it compat.

I thought about hashing packages with only the repo name and not the full path. I think you are right. I will implement it soon.

Utils.lua is currently getting rehashed because of certain weird bugs I am encountering. I am making a more robust version of utils.lua. You can check it out in a few days.

Regarding the global table, there is no other way of making lua functions behave well with autocmds. Anyway, those lamdas stay in memory as long as the keybinding is loaded so putting them in _G with an anonymous name seems similar to your suggestion.

[LuigiPiucco]

Hi again. Thanks for allowing me to use parts of your code, especially since I may have jumped the gun and added it to my repo early... Also, don't feel bad or anything, please maintain your code and, if so desired, contribute here. I just now noticed you didn't fork, instead creating a new repo. There wasn't really coercion, make suggestions and changes as you'd like, I hope I wasn't unwelcoming.

[caligian]

Hi, which functions have you used? I rewrote utils.lua to a good extent. The current commit is a little wonky - especially the hooking and keybinding function. I will post a commit today, maybe use that because it is more robust

[LuigiPiucco]

This was the main inspiration for this commit, it implements something very similar to your piece, just with functions under a _G._doom.autocmd_funcs[id] namespace instead of just _G[name]. Also, I went with unique IDs rather than names, just because my intention was implementing anonymous autocmds only, but your implementation with names would double as a global function store and maybe allow the user to override what the function does (though here I think we can just tell them to empty the augroup and set their own). I tried to make my commit as original as I could, so as to not "just copy and paste" without permission, which would be bad in open-source, but there are still similarities.

I also proposed to merge some basic editor modules onto core, like you have done, but other contributors were against that. Another thing was flattening the module structure as you suggested in the other thread, and I can say it is much better without '[category][module]' everywhere, plus it may have reduced iteration cost.

[caligian]

Wow. You just solved the whole unique naming problem. In my new implementation, I had resorted to using explicit unique naming because of random numbers somehow being the same and causing a function to get bound to unrequired mappings. I can just push a lamda onto an array and ref it with its index without the overhead of taxing the global table with big names