feat(modules): make modules very granular
These changes have been discussed in #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.
3 years ago
|
|
|
--
|
|
|
|
|
-- modules.lua - Doom nvim module selection
|
feat(modules): make modules very granular
These changes have been discussed in #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.
3 years ago
|
|
|
-- modules.lua controls what Doom nvim plugins modules are enabled and
|
|
|
|
|
-- what features are being used.
|
|
|
|
|
--
|
|
|
|
|
-- Uncomment a plugin to enable it and comment out to disable and uninstall it.
|
|
|
|
|
|
|
|
|
|
return {
|
|
|
|
|
features = {
|
|
|
|
|
-- Language features
|
|
|
|
|
"annotations", -- Code annotation generator
|
|
|
|
|
"auto_install", -- Auto install LSP providers
|
|
|
|
|
"autopairs", -- Automatically close character pairs
|
|
|
|
|
"comment", -- Adds keybinds to comment in any language
|
|
|
|
|
"linter", -- Linting and formatting for languages
|
|
|
|
|
"lsp", -- Code completion
|
|
|
|
|
"snippets", -- Code snippets for all languages
|
|
|
|
|
|
|
|
|
|
-- Editor
|
|
|
|
|
"auto_session", -- Remember sessions between loads
|
|
|
|
|
"colorizer", -- Show colors in neovim
|
|
|
|
|
"editorconfig", -- Support editorconfig files
|
|
|
|
|
"gitsigns", -- Show git changes in sidebar
|
|
|
|
|
"illuminate", -- Highlight other copies of the word you're hovering on
|
|
|
|
|
"indentlines", -- Show indent lines with special characters
|
|
|
|
|
"range_highlight", -- Highlight selected range from commands
|
|
|
|
|
"todo_comments", -- Highlight TODO: comments
|
|
|
|
|
|
|
|
|
|
-- UI
|
|
|
|
|
"lsp_progress", -- Check status of LSP loading
|
|
|
|
|
"tabline", -- Tab bar buffer switcher
|
|
|
|
|
"dashboard", -- A pretty dashboard upon opening
|
|
|
|
|
"trouble", -- A pretty diagnostic viewer
|
|
|
|
|
"statusline", -- A pretty status line at the bottom of the buffer
|
|
|
|
|
-- "minimap", -- Shows current position in document
|
|
|
|
|
|
|
|
|
|
-- Tools
|
|
|
|
|
-- "dap", -- Debug code through neovim
|
|
|
|
|
"explorer", -- An enhanced filetree explorer
|
|
|
|
|
-- "firenvim", -- Embed neovim in your browser
|
|
|
|
|
"telescope", -- Fuzzy searcher to find files, grep code and more
|
|
|
|
|
"neorg", -- Organise your life
|
|
|
|
|
"whichkey", -- An interactive sheet
|
|
|
|
|
"projects", -- Quickly switch between projects
|
|
|
|
|
|
|
|
|
|
-- "doom_themes", -- Extra themes for doom
|
|
|
|
|
-- "lazygit", -- Lazy git integration
|
|
|
|
|
-- "neogit", -- A git client for neovim
|
|
|
|
|
-- "ranger", -- File explorer in neovim (TODO: Test)
|
|
|
|
|
-- "restclient", -- Test HTTP requests from neovim (TODO: Test)
|
|
|
|
|
-- "show_registers", -- Show and navigate between registers
|
|
|
|
|
-- "suda", -- Save using sudo when necessary
|
|
|
|
|
-- "superman", -- Read unix man pages in neovim
|
|
|
|
|
-- "symbols", -- Navigate between code symbols using telescope
|
|
|
|
|
-- "terminal", -- Integrated terminal in neovim
|
|
|
|
|
},
|
|
|
|
|
langs = {
|
|
|
|
|
-- Scripts
|
|
|
|
|
"lua",
|
|
|
|
|
-- "python",
|
|
|
|
|
-- "bash",
|
|
|
|
|
|
|
|
|
|
-- Web
|
|
|
|
|
-- "javascript",
|
|
|
|
|
-- "typescript",
|
|
|
|
|
-- "css",
|
|
|
|
|
-- "vue",
|
|
|
|
|
-- "tailwindcss",
|
|
|
|
|
|
|
|
|
|
-- Compiled
|
|
|
|
|
-- "rust",
|
|
|
|
|
-- "cpp",
|
|
|
|
|
|
|
|
|
|
-- JIT
|
|
|
|
|
-- "c_sharp",
|
|
|
|
|
-- "kotlin",
|
|
|
|
|
-- "java",
|
|
|
|
|
|
|
|
|
|
-- "config", -- JSON, YAML, TOML
|
|
|
|
|
-- "markdown",
|
|
|
|
|
}
|
feat(modules): make modules very granular
These changes have been discussed in #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.
3 years ago
|
|
|
}
|
|
|
|
|
|
|
|
|
|
-- vim: sw=2 sts=2 ts=2 fdm=indent expandtab
|
