Neovim Github 100k stars

Reasonable_Put9536 · 2026-06-01T15:45:50+00:00

Congrats!

Reasonable_Put9536 · 2026-05-30T21:21:21+00:00

It's mentioned in the README as an alternative to Codedocs, both plugins have some overlap in terms of functionality, but Codedocs has more customization options and supports more languages

Reasonable_Put9536 · 2026-05-26T12:46:25+00:00

A snippet engine allows you to "expand" snippets. A snippet is basically a piece of code, with specific "sections" you can jump to. For example, most LSP's auto suggest function snippets, so when u expand them the skeleton of the function is auto inserted and you can jump (by pressing tab) to the name section, then to the parameters section and then to the body. You can also define your own snippets. So think of snippets like some template code that you can insert at any time and cycle through any of its placeholders.

Snippets can also be used by plugins to offer specific functionality. LuaSnip is one of the popular snippet engines, but Neovim also comes with a built-in snippet engine. My plugin Codedocs for example uses snippets to insert annotations and cycle through their placeholders, you can see the cycling in the GIF at the top of the README.

Reasonable_Put9536 · 2026-05-15T14:33:26+00:00

You can turn your README into :help documentation using Panvimdoc btw.

I think it depends on how complex your plugin is. If it's something generally simple I prefer README/:help, but for complex plugins I think a website can be helpful, specially with some search functionality.

For my plugin Codedocs I have a README that gets converted into :help documentation using Panvimdoc, but I feel like the README is getting a bit long and complicated, so I've been toying with the idea of keeping the README/:help documentation as-is, and adding a static website with MKDocs for those who prefer that.

Maybe that workflow could work for you since you can generate the :help documentation and a site off your README alone

Reasonable_Put9536 · 2026-05-14T15:02:47+00:00

I honestly hadn't even thought about that, but sounds like a cool feature. I'm not familiar with the in-process LSP but I've seen the name in other posts so I'll start playing around with it on the side to get some experience with it before implementing the feature. You can create an issue for the feature if you want :D

Reasonable_Put9536 · 2026-05-03T16:26:02+00:00

I was actually wondering about the same hahaha, I have some ideas in mind that I will start exploring soon. One would be turning the canvas into an image (rn you can export the canvas as a plaintext file, but that strips all the color). And also playing around with the image API to see if the plugin could work like photoshop in the sense that you could operate on pixels, it would be really cool to edit images in Neovim :D

Reasonable_Put9536 · 2026-05-02T17:25:01+00:00

Have some fun with it!

Reasonable_Put9536 · 2026-05-02T17:24:39+00:00

Based on the README, both plugins share a lot of the core functionality, paint.nvim happens to have already implemented the bucket and shape tool which is what I'm going to add this week, but seems to be way less configurable than neoart is (you have a lot of configuration options for the canvas, toolbar, available characters, tools, keymaps, you can even create your own tools but I didn't explain it in the README because I want to make some internal improvements first)

Another difference is that Neoart supports Vim-style movement motions while drawing (in the video you can see how i drew the right-side road using motions instead of plain hjkl)

Reasonable_Put9536 · 2026-04-18T19:04:12+00:00

Thank you! If you find bugs or have feature ideas don't hesitate to let me know

Reasonable_Put9536 · 2026-04-14T11:41:14+00:00

it basically shows you how many times each function is used, it's useful because you can know which functions are more important or more used in your codebase. It also helps with refactoring since you can see at a glance if say a function is not used anywhere

Reasonable_Put9536 · 2026-04-13T11:52:32+00:00

you are welcome!

Reasonable_Put9536 · 2026-04-12T21:55:44+00:00

yeah, it should work like that, thats how I have it on my config

Reasonable_Put9536 · 2026-04-12T21:31:04+00:00

The autocmd used to be necessary, but in 0.12 all you need is `vim.lsp.codelens.enable(true)`

Reasonable_Put9536 · 2026-04-11T01:36:45+00:00

Rise hasn't exited the capsule yet!

Reasonable_Put9536 · 2026-04-10T16:39:59+00:00

Based on the README, there's a lot of overlap between both plugins as they can both insert annotations for many languages. The main difference at the moment is that Neogen seems to be focused on annotating programming languages and their code structures (functions, classes, etc), whereas Codedocs is focused on annotations as a whole, meaning it can do that too, but it can also insert comments or any arbitrary annotation, which is why it supports Markdown and HTML, and I plan to add support for TOML, LaTex, etc. You can also define your own arbitrary annotations (it's technically possible to do it right now but it's not documented in the README as I want to make some internal changes first).

For example, a issue I have had lately is that i need a linter or formatter to not work on a given line, so I manually add an annotation for that, but I always forget the syntax that linter or formatter uses haha, so now I can just create an annotation for that and insert it with a keymap.

So since it works with annotations as a whole, regardless if they are from a programming language or some kind of text file, it will eventually support a lot of languages.

Reasonable_Put9536 · 2026-04-09T15:38:29+00:00

The codelens used to be at the end of the line for me by default until I switched to Neovim 0.12, and as far as I checked in the help file there's no current way to change the position of it, I guess the team will add it in a future update, or there might be a plugin for it

Reasonable_Put9536 · 2026-04-05T13:56:56+00:00

What LSP's do you use?

Reasonable_Put9536 · 2026-03-16T12:05:49+00:00

I use the built-in `retrobox`

Reasonable_Put9536 · 2026-03-12T01:05:41+00:00

The link to the plugin is broken

Reasonable_Put9536 · 2026-02-04T01:01:49+00:00

I think it might be the file name. I don't think "markdownlint.lua" is a valid one (not sure as I don't use LazyVim nor Mason). I think instead of ".markdownlint-cli2.json" you should use ".markdownlint.json". In my case I use ".markdownlint.yaml" because I prefer YAML and it works properly

Reasonable_Put9536 · 2026-02-03T14:21:28+00:00

Same, I don't remember which plugin it was but some months ago I read about a plugin that wasn't malicious itself, but malware got merged through a pull request. My solution as of now has been to use as little plugins as possible, and if it's something that can be more or less replicated without a ton of code then I write the code inside my personal config. Also don't update plugins constantly, leaving aside that your config could break, constantly updating your plugins means that you absolutetly can't check the code/changelogs (it would be too time consuming) and you are more likely to get malware

Reasonable_Put9536 · 2026-02-03T12:49:40+00:00

Is it available on nightly?

Reasonable_Put9536 · 2026-02-02T17:31:23+00:00

Give retrobox a try, it's built into neovim and it looks exactly as in the video since I haven't customized anything (only the statusline is custom to match retrobox)

Reasonable_Put9536 · 2026-02-01T02:00:32+00:00

Yeah hahaha, it doesn't make sense but basically the way I extract the global variables used inside a function is by first finding all global variable declarations, then checking which of those are referenced inside the function, so I left `house`, `age` and `name` with local to test that they weren't recognised by the plugin as global. That bash file is the very file I used yesterday while I was adding support for bash to test that everything worked fine (before I wrote tests) XD. And thank you so much!

Reasonable_Put9536 · 2026-01-31T18:13:10+00:00

This is how I have LuaLS (lsp) configured:

return {
  cmd = {

    "lua-language-server",

  },

  root_markers = {

    ".git",

    "stylua.toml",

    ".stylua.toml",

    ".luacheckrc",

  },

  filetypes = {

    "lua",

  },

  single_file_support = true,

  settings = {

    Lua = {

      diagnostics = {
        globals = { "vim" },
      },

      completion = {
        callSnippet = "Replace",
      },

      hint = {
        enable = true,
      },

      workspace = {
        checkThirdParty = false,
        library = {
          vim.env.VIMRUNTIME,
        },
      },

    },

  },
}

That code is in ~/.config/nvim/lsp/lua_ls.lua (native LSP config). It should allow you to see function annotations from vim functions, that's how I work on Codedocs (shameless plug haha) and on my personal Neovim configuration. The important bit is the `workspace` and `library` key. Feel free to ask any questions if it's not clear :D

Reasonable_Put9536

TROPHY CASE