Giters

nvimtools / none-ls.nvim

null-ls.nvim reloaded / Use Neovim as a language server to inject LSP diagnostics, code actions, and more via Lua.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Adopting cspell.nvim into nvimtools org

eshepelyuk opened this issue · comments

commented

Hello

To start expanding the ecosystem I would like to suggest to adopt this plugin https://github.com/davidmh/cspell.nvim into nvimtools organisation.

If author agrees it could become a starting point of reorganizing and modularizing current repository into smaller plugins that can be maintained by community members.\

commented

You are more than welcomed to submit a pull request! I don't have much motivation as I'm not using cSpell myself.

commented

You are more than welcomed to submit a pull request! I don't have much motivation as I'm not using cSpell myself.

How one can provide a PR for such a request ? Plz explain.

commented

Consider porting the plugin directly into this repo instead of having a new one, to reduce maintenance burden, thanks ;)

commented

Please test: 2782d44

commented

This commit remove cspell doc. Do you know why? @mochaaP
68645e56d10b5120a3fdc7467601f1ea497635e6

commented

Thanks all contributers work!

For someone don't know how to use the new cspell.nvim, a minimal config can be :

{
    "nvimtools/none-ls.nvim",
    dependencies = "davidmh/cspell.nvim",
    config = function()
        local null_ls = require("null-ls")
        local cspell = require("cspell")
        local cspell_config = {
            diagnostics_postprocess = function(diagnostic)
                diagnostic.severity = vim.diagnostic.severity["HINT"] -- ERROR, WARN, INFO, HINT
            end,
            config = {
                find_json = function(_)
                    return vim.fn.expand("~/.config/nvim/cspell.json")
                end,
                on_success = function(cspell_config_file_path, params, action_name)
                    if action_name == "add_to_json" then
                        os.execute(
                            string.format(
                                "cat %s | jq -S '.words |= sort' | tee %s > /dev/null",
                                cspell_config_file_path,
                                cspell_config_file_path
                            )
                        )
                    end
                end,
            },
        }
        null_ls.setup({
            sources = {
                cspell.diagnostics.with(cspell_config),
                cspell.code_actions.with(cspell_config),
            },
            handlers = handlers,
            on_attach = on_attach,
        })
    end,
},

You can also find a more complete example at: https://github.com/keaising/dotfile/blob/f9151328fbe34f3c673bc6ba444da11753ce82f6/nvim/.config/nvim/lua/plugins/lsp.lua#L168-L260

commented

Glad to hear that! Should I keep the cSpell support in this repo as-is, or remove it?

commented

In my personal opinion, for two reasons I think its better to add a deprecate tag to cspell in this repo, and add a redirect link to the new cspell.nvim in doc, break change list or readme:

  1. cspell is one of the most complicated builtin in null-ls, jose-elias-alvarez want to divide it from null-ls before. jose-elias-alvarez/null-ls.nvim#1466 (comment) . Now, we have a good enough uniquecspell.nvim, I think we can replace cspell in none-ls with it.
  2. But for some users of none-ls, removing cspell in none-ls directly, without no notice will bring break change to them and confuse them.
commented

@keaising I've granted you permissions on this repository, feel free to implement it :)

commented

I don't understand why should we make it a separate repo. Just because it is complex?

commented

I don't understand why should we make it a separate repo. Just because it is complex?

becaus it was one of the issues with null-ls that previous author wanted to address, by moving out builtins to separated "extensions".

So the core maintainers won't spend tons of time on supporting about hundred of existing builtins, but offload this duty to those new "extension" maintainers.

commented

Yeah, the main reason is that cspell is too complex and has too many args and options, it's hard for null-ls's maintainer to maintain it, because few maintainer know about cspell.

In the new separate repo, maintainers have enough knowledge about cspell, they can add new features and fix bugs in time, I think this is a better choice for the users of cspell.

On the other side, as long as the new repository is compatible with the existing repository in terms of interface, users will not be affected, I mean this:

        null_ls.setup({
            sources = {
                cspell.diagnostics.with(cspell_config),
                cspell.code_actions.with(cspell_config),
            },
        })

BTW, I think this is also a good way to keep null-ls alive: users maintain the plugins themselves and the plugins interface with the null-ls, so there's less pressure on null-ls's maintainers.