Ignoring invalid config key 'src.cmp'

[palozano]

Description

Getting the message "Ignoring invalid config key 'src.cmp'" after fresh install, with default configs (copy-pasted), not modified.

Neovim version

NVIM v0.9.4

Operating system and version

macOS Ventura 13.5.1 (22G90)

Expected behavior

No response

Actual behavior

I get the message but still can call the functions to upgrade, open the features popup...

Minimal config

-- comment out, and add the things that are _necessary_ for reproducing the ISSUE
for name, url in pairs({
    crates = "/home/tobi/Projects/crates.nvim",
    plenary = "https://github.com/nvim-lua/plenary.nvim",
    -- cmp = "https://github.com/hrsh7th/nvim-cmp",
    -- coq = "https://github.com/ms-jpq/coq_nvim",
    -- null_ls = "https://github.com/jose-elias-alvarez/null-ls.nvim",
}) do
    local install_path = vim.fn.fnamemodify("crates_issue/" .. name, ":p")
    if vim.fn.isdirectory(install_path) == 0 then
        vim.notify("cloning " .. url .. " into " .. install_path)
        vim.fn.system({ "git", "clone", "--depth=1", url, install_path })
    end
    vim.opt.runtimepath:append(install_path)
end

require("crates").setup({
    src = {
        -- cmp = { enabled = true },
        -- coq = { enabled = true },
    },
    -- null_ls = { enabled = true },
})

-- require("cmp").setup({
--  sources = { { name = "crates" } },
-- })

-- require("null-ls").setup({
--  on_attach = function(client, buf)
--      vim.keymap.set("n", "<space>a", vim.lsp.buf.code_action, { buffer = buf })
--  end,
-- })

Cargo.toml

None

Steps to reproduce

1. nvim --clean -u minimal.lua
2. ...

[saecki]

Can't reproduce, what version of crates.nvim are you using?

[ghost]

I am having the same error. I am using crates.nvim 0.4.0(main branch, commit: 8437522, tag: stable)

[DoctorApparatus]

Same issue here. Using the nightly nvim build and same crates.nvim version

[saecki]

Oh right, on 0.4 that key doesn't exist, and the configuration in the readme is automatially updated, so it shows the one on main.

I wonder what's the best way to go about this, I can think of a few options

1. Only show the stable configuration in the readme
2. Move the entire documenation inside a wiki and make a stable and unstable section
3. Just leave it as is, which is apparently confusing

What do you think?

[DoctorApparatus]

imho, I think putting everything into a wiki would be the cleanest solution since that way stable and unstable can cleanly be differentiated even though it's some initial overheads but might pay out later if the documentation needs more details down the road