Closed wroyca closed 2 months ago
Does this PR follow the [Contribution Guidelines](development guidelines)? Following is a partial checklist:
Proper conventional commit scoping:
If you are adding a new plugin, the scope would be the name of the category it is being added into. ex. feat(utility): added noice.nvim plugin
If you are modifying a pre-existing plugin or pack, the scope would be the name of the plugin folder. ex. fix(noice-nvim): fix LSP handler error
[ ] Pull request title has the appropriate conventional commit type and scope where the scope is the name of the pre-existing directory in the project as described above
[ ] README
is properly formatted and uses fenced in links with <url>
unless they are inside a [title](url)
[ ] Proper usage of opts
table rather than setting things up with the config
function.
This is not a good approach because of this notice: https://github.com/neoclide/coc.nvim/blob/master/doc/coc.txt#L1843-L1845
Note: those configuration would overwrite the configuration from the user's settings file, unless you have to use some dynamic variables, using the settings file is recommended.
This is not a good approach for configuration for a shared configuration that users can override.
Also the interaction with neodev
is also incorrect. Part of the advantage of neodev
is that it doesn't mess up the lua language server for non-neovim lua projects which this setup would do as well. It would be nice to add good integration in the language packs for coc but as it stands currently and the way coc.nvim is configured it is highly not recommended to do it this way especially in an environment where people will want to change values.
This is not a good approach because of this notice: https://github.com/neoclide/coc.nvim/blob/master/doc/coc.txt#L1843-L1845
Note: those configuration would overwrite the configuration from the user's settings file, unless you have to use some dynamic variables, using the settings file is recommended.
This is not a good approach for configuration for a shared configuration that users can override.
Also the interaction with
neodev
is also incorrect. Part of the advantage ofneodev
is that it doesn't mess up the lua language server for non-neovim lua projects which this setup would do as well. It would be nice to add good integration in the language packs for coc but as it stands currently and the way coc.nvim is configured it is highly not recommended to do it this way especially in an environment where people will want to change values.
Make sense, unfortunate that user configuration doesn't override, thank for the review!
📑 Description
This PR is a draft to add better defaults to coc.nvim and fix some compatibilities with plugins (e.g. Neodev). There's a lot of area that I'm not sure how to approach due to AstroNvim abstraction, so if anyone wants to review, it's probably best to go ahead by pushing commits directly on the PR without worries, I will sync and rebase locally
Remaining things to do:
ℹ Additional Information