Community Feedback Requested

[mrjones2014]

I would like to start stabilizing the legendary.nvim API, and introduce semantic versioning using git tags. This will help me prepare for the future of legendary.nvim, which may or may not involve a rewrite.

I rewrote the plugin once from Lua to Teal (a statically typed language which compiles to Lua), but it didn't have as much payoff as I'd hoped, and the editor tooling around Teal is quite sub-par. Now that we have nvim-oxi I could potentially rewrite into Rust, which would give me the payoff I was hoping Teal would give me.

Such a rewrite would also allow me to correct a lot of poor design decisions I made along the way -- legendary.nvim started very simple and added a bunch of features, which significantly increased the complexity.

TL;DR

There's potentially going to be a very long-running project coming up for legendary.nvim to improve developer tooling and reduce complexity. For this reason, I would like to stabilize the API and introduce semantic versioning via git tags. Before doing so, I would like to know from the community if there are any pressing issues that should be addressed or any missing functionality that can be quickly added.

[mrjones2014]

Here are some specific questions I'd love for you all to answer:

• Is legendary.nvim an important part of your Neovim config? If so, how important, on a scale of 1-10?
• Is your legendary.nvim configuration hosted somewhere I can look at it? If so, please drop a link, I'd love to observe how everyone is using legendary.nvim
• What features do you use most from legendary.nvim? Are there any features you rarely or never use?
• Are there any design decisions or limitations (other than loading data automatically from Neovim's API, see Implement an API to auto-load commands, autocmds, and keymaps from the nvim API #39) that you disagree with or think could be improved?
• Is there anything specific you think should be improved or added before cutting a 1.0.0 semantic versioned release of legendary.nvim?

[mrjones2014]

Tagging @olimorris since you always have great feedback ❤️

[olimorris]

• Is legendary.nvim an important part of your Neovim config? If so, how important, on a scale of 1-10?
  Absolutely core. If I define 10 as "cannot use Neovim without it" then I'd give it an 8. I now do not have to actively remember commands. If I forget keymaps then hey they're just a and a keystroke or two away.

• Is your legendary.nvim configuration hosted somewhere I can look at it? If so, please drop a link, I'd love to observe how everyone is using legendary.nvim
  My legendary config, my lsp bindings which all point to my autocmds, commands and keymaps

• What features do you use most from legendary.nvim? Are there any features you rarely or never use?
  I guess I'd say "I don't know what I don't know". I keep an eye on your dotfiles to make sure I'm not missing anything 😉 .

• Are there any design decisions or limitations (other than loading data automatically from Neovim's API, see Implement an API to auto-load commands, autocmds, and keymaps from the nvim API #39) that you disagree with or think could be improved?

• Is there anything specific you think should be improved or added before cutting a 1.0.0 semantic versioned release of legendary.nvim?
  For myself, it's near perfect as-is. I always think in software we tend to think nothing is feature complete. Yet with the ecosystem we find ourselves in, we should be ready to say "This is done and I'll update it for bug fixes and new neovim functionality, but I'm happy with it".

[mrjones2014]

Are you using the visual selection/marks passed to callbacks anywhere? I'm thinking of removing this functionality in the next version, for a few reasons.

• You can get the marks from the Neovim API anyway (I can provide a helper for this)
• It prevents you from creating commands that take arguments via legendary.nvim, because the args passed by Neovim are ignored, and instead the visual selection/marks are passed to the user's callback

So, I'm thinking in V2 of making it so that everything is bound/registered very directly, so that, for example, you can create commands that take arguments.

[olimorris]

Do you mean something like this:

{
    "gcc",
    function(visual_selection)
        if visual_selection then
            require("Comment.api").toggle.linewise(vim.fn.visualmode())
        else
            require("Comment.api").toggle.linewise.current()
        end
    end,
    description = "Comment toggle",
    mode = { "n", "x" },
},

If so, then yes 😄 .

[mrjones2014]

Would it work for you if it instead looked something like this:

{
    "gcc",
    function()
        -- not sure what the actual module path would end up being yet
        -- but as an example:
        if require('legendary.tools').is_visual_mode() then
            require("Comment.api").toggle.linewise(vim.fn.visualmode())
        else
            require("Comment.api").toggle.linewise.current()
        end
    end,
    description = "Comment toggle",
    mode = { "n", "x" },
},

I could also provide a get_marks() function to return the visual mode marks.

[olimorris]

Oh absolutely. Quite like the idea of having some legendary helper tools to reference as well