This repository has been archived by the owner on Apr 16, 2024. It is now read-only.
[WIP] feat: Implemented new proposed modular architecture + config changes #313
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
These changes have been discussed in doom-neovim#233. As a side note, I ran stylua and luacheck over the repo. * From everyone's perpective - The module structure has been flattened out, removing the category grouping. Beyond less iteration scopes, this may help with, in the future, allowing the user to write and enable custom modules in $DOOMDIR. * From the user's perpective - `doom_config.lua` works via overrides now, it can change defaults on the global `doom` before everything gets actually configured. - `doom_modules.lua` just returns the actual thing it's supposed to, without {return value}.source. More on that next. - Instead of each config file returning a source key with its file location, the handlers for each config file actively search for them. This is described in the respective files inside `lua/doom/core/config`, but it's basicaly a check for two special paths falling back to runtimepath. - `doom_userplugins.lua` is removed in favor of having its functionality in `doom_config.lua`. To add a standalone package, add its packer spec to `doom.packages` (this is a map-like table of package names to packer specs). - To override the spec of a module package, change the keys in `doom.packages[package_name_without_author]`. Special attrs: `config` is run after the built-in config. - To change settings and behavior, override keys in `doom[module]`, or just `doom.*` for some core features. - To add standalone bindings, add them to `doom.binds`. This is passed to nest along with the modules' binds. `doom.binds` overrides anything you don't like in modules, you can safely replace the bind. - To add standalone autocmds, add them to `doom.autocmds[augroup_name]`. The structure is as passed to `utils.create_augroups`, so: ```lua doom.autocmds[group_name] = { { event1, pattern1, cmd1 }, ... } ``` - You shouldn't override any tables, like `doom.autocmds` or `doom.packages`, only the leaves, else you remove all that is already there. We could use metatables to avoid this in the future. - The `config.nvim` table is no longer used, most of its functionality is spread elsewhere, like autocmds. For variables and options, just use vim.opt.*, vim.g.* etc. in `doom_config.lua` - Settings can also be appended to in `doom_config.lua`, because defaults are prepopulated. * From a maintainer's perpective - Most things are grouped under the `doom` global, which is populated and overriden early in `init.lua`. The exception is enabled modules, which you still need to require `doom.core.config.modules` to get. However, do so sparingly, and only if you truly mean to iterate over enabled modules disregarding user overrides (they may have removed a particular package or reset binds). - Modules are defined in the following folder structure inside `lua/doom/modules`: `<module>/{init.lua,packages.lua,binds.lua,autocmds.lua}`. init.lua and packages.lua are required, even if empty. - `init.lua` returns: defaults under a `defaults` key; config functions under `packer_config[package_name]`. It can access the doom global only inside the configs. - `packages.lua` returns: a map of package names to package specs, with no `config` or `disable` keys present. Most things should be lazy-loaded, preferably with the `cmd` and `module` keys. It cannot access the doom global. - `autocmds.lua` returns: a list of autocmds to be applied under the group `doom_{module}`. It can use the `doom` global to add things conditionally. - `binds.lua` returns: the keyconfig to be passed to nest. It can use the `doom` global to add things conditionally. What's left: - Implement lsp wrapping. - Document the individual modules. - Write a migration script.
This adds wrapping of lsp for one language: lua. It adds two modules, `auto_install` and `lua`. The former toggles auto installation, and is sort of a marker module. Beyond installing and configuring nvim-lsp-installer and DAPInstall.nvim, it doesn't really do anything. It's purpose is to be checked on the lua module which will use the installers if it is enabled. Otherwise just falls back to $PATH. Since I'm on NixOS, I can only test the non-auto installation, but it seems to be downloading properly for the auto version. The lua module also installs additional packages, namely lua-dev.nvim, which used to be part of the lsp module. It could add keybinds, but I couldn't think of any. It has a special autocommand that `dofile`s the config.lua, which actually sets up lsp (and possibly dap) lazily and only after the first lua file is opened. This commit is meant as a template/prototype to other language wrappings.
Also remove the built-in modules in favor of putting them inside utils (reloader and async) or implementing them later with the new module structure (others).
Now supports lua functions. The ideas come from @caligian and his repo, though modified to use a unique index instead of requiring a name.
…dule. Also fixes issues with the kommentary module and provides new behaviour `gcA` to add comment to end of line.
Previously ran on BufNewFile,BufRead.
Fixes issues with the kommentary module and provides new behaviour such as `gcA` to add comment to end of line.
connorgmeehan
force-pushed
the
feature/module-architecture-2
branch
from
0400bcc
to
303ae42
Compare
added 21 commits
April 5, 2022 21:17
…eased legibility and documentation.
added 6 commits
May 7, 2022 13:55
…ure-2 # Conflicts: # config.lua # init.lua # lua/doom/core/config/init.lua # lua/doom/modules/features/doom_reloader/init.lua # lua/doom/modules/init.lua # lua/doom/modules/langs/tailwindcss/init.lua # lua/doom/modules/langs/typescript/init.lua # modules.lua
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes:
doom_modules.luanow organised just byfeatures,langs, and an optionalusercategory.doom_config.lua, is nowconfig.luaand can set the same settings imperatively usingdoomglobal object.doom.use_package,doom.use_bind,doom.use_cmd,doom.use_autocmdto add packages, binds, cmds and autocmds inconfig.luafile. (STILL WIP)formatterandlintermodule (now justlinter) -> uses null-ls.lsp_progressmodule: uses fidget.nvim to show LSP indexing/loading progress.annotationsmodule: uses neogen to generate code annotations/documents. Can anyone think of a better name?nvim-tree-docsplugin that was installing by defaultkommentarymodule, nowcomments(try to keep module name generic) usesComment.nvimto generate comments.lua, markdown, python, rust, tailwindcss, teal, terraform, typescript, vue.
This PR is to track the final changes on the new modular architecture. There are still a few tasks outstanding:
doom.usetodoom.use_packagedoom.use_bind,doom.use_cmd,doom.use_autocmdfunctionslua/doom/modules/core/tolua/doom/modules/internal/(I think core makes more sense to refer to the doom nvim framework and internal makes more sense as the internal modules that allow doom nvim to work).Once it's merged:
doom.<option>config options are working correctly. (@NTBBloodbath you might understand these best)