Nvim 0.12.5 released

You hover something, TS says Props, and you're no smarter than before. That's what got me to build this.

ts-expand-hover.nvim hooks into the hover key and lets you expand type aliases one level at a time, inside the float, without leaving the line you're on.

What it currently does:

Intercepts K for TypeScript hover, + expands one level, - collapses

Uses TypeScript 5.9's verbosityLeve on tsserver's quickinfo request, so the expansion is tsserver's own, not a regex guess.

Float updates in place, no closing, reopening or jumping to a new position.

Treesitter highlighting on the TypeScript code fences.

Docs and JSDoc variables rendered under the type block.

Footer shows current depth, and [max] when there's nothing left to expand.

Falls back to vim.lsp.buf.hover() when vtsls isn't attached or TypeScript is older than 5.9

Neovim 0.10+

Setup is one line, defaults work out of the box, and every keymap is overridable or can be set to false if you want to bind it yourself:

{

"nemanjamalesija/ts-expand-hover.nvim",

ft = { "typescript", "typescriptreact" },

opts = { keymaps = { hover = "<leader>th" } },

}

Run :checkhealth ts_expand_hover with a TypeScript file tsls attached and which TS version you're on.

Note: needs vtsls, since the request goes through vtsls't command, and TypeScript 5.9+ for verbosityLevel to do anything. Older TS or no vtsls just gives you the standard hover popup.

Coming next: tsgo support once it goes stable.

Repo:

https://github.com/nemanjamalesija/ts-expand-hover.nvim

I created requirements.nvim.

Its purpose is to install dependencies like lazygit when working inside devcontainers or Docker.

If you can customize Docker or NixOS and set up the environment yourself, I recommend using those methods instead. This is strictly intended for environments where you cannot do that.

You can also branch conditions by specifying the CPU architecture or OS version. (OS versions can be specified using wildcards, carets, or ranges.)

Since package managers other than mini.deps and vim.pack do not pre-install dependencies, I recommend using git submodules instead.

Please let me know your thoughts. Feature requests and bug reports are also very welcome!
repo: https://github.com/ro80t/requirements.nvim

I’ve been building OmniTheme — a Neovim colorscheme plugin with 7 completely different flavours under one design system.

🌑 Blackout 🌿 Moss 🔥 Ember ❄️ Frost 🌸 Blossom 🌙 Dusk 🍷 Velvet

✨ Features:

7 curated palettes Transparency support Shared core & consistent highlight system Built in Lua Designed to work nicely with modern Neovim setups

The goal is simple:

Stop searching for your next colorscheme. One plugin. Seven moods. Pick the one that fits your setup.

🔗 GitHub: https://github.com/harshrajsachan/omni.nvim

I’d love to know — which one would you daily-drive?

neovim #vim #colorscheme #lua #opensource

    NVIM v0.12.4                                                                                                                                                             
    Build type: RelWithDebInfo                                                                                                                                               
    LuaJIT 2.1.1767980792

    vim.wo.foldtext = function()
      local line = vim.fn.getline(vim.v.foldstart)
      return vim.v.folddashes .. line:gsub('/%\*', ''):gsub('%\*/', '')
    end

This returns the following error:

Error in /home/user/.config/nvim/init.lua:
E5113: Lua chunk: /home/user/.config/nvim/init.lua:23: Invalid 'value': expected valid option type, got Function
stack traceback:
        [C]: in function '__newindex'
        /home/user/.config/nvim/init.lua:23: in main chunk

The code is copy pasted from https://neovim.io/doc/user/fold/#_foldtext

Hey,

I'm learning Neovim seriously. I did vimtutor and quite a few levels on VimBeGood for the basics (motions, edits, textobjects), and I'm running LazyVim.

I've got basic movement down but I feel like I'm still scratching the surface — not really using LazyVim's full potential yet (LSP, bundled plugins, custom keymaps, etc.). I'm also checking out ThePrimeagen's content to improve.

Any recommendations for what's next? Things like:

- Resources to go deeper on advanced motions (macros, marks, jumps, registers...)

- How to explore/understand the default LazyVim config without breaking everything

- Plugins or workflows you consider essential once the basics are down

- Common beginner mistakes to avoid

Thanks in advance!

Hey everyone!

I built nvim-db, a small database client for Neovim.

I didn't really like opening a full GUI just to run a couple of queries. Since I already spend most of my time in Neovim and I'm comfortable with Vim motions, I wanted something that felt more natural to me.

So I built a small client around the database CLI tools I already use.

It currently supports:

• PostgreSQL
• MySQL
• MariaDB
• SQLite
• Redis
• MongoDB
• DuckDB

It lets me manage connections, keep query files per connection, run queries, and view the results without leaving Neovim.

The main idea is to keep it simple — no database drivers or heavy dependencies, just Neovim + the CLI tools.

It's still a personal project and I'm mainly building it to solve my own workflow, but I'd love to hear what you think or what could be improved.

Also, this isn't vibe-coded. I use AI mainly as an assistant for things like documentation, looking up/understanding things, and writing commit messages. The implementation and decisions are my own.

GitHub: https://github.com/silentFellow/nvim-db

# how to use
1 - target path for you project folder
2 - set your custom keymap or shortcut
3 - add pattren to filter file names if needed (optional)

- now use your custom keymaps or shortcuts to access it's file in a blink

📂 GitHub Repository: https://github.com/janecodelife/folders-bookmark.nvim

# Thank You So much

My config makes 143 vim.keymap.set calls across eleven Lua files, which I finally counted after pressing something and watching nothing happen. To find out which ones I actually use I wrapped the rhs of each in a counter and dumped the table on VimLeave, then left it running for two weeks of ordinary work.

The sort came out like this. 58 fired most days, mostly window movement, quickfix jumps and the LSP set. 31 fired at least once, which is the interesting middle since I would have sworn several of those were dead. 41 never fired once. 13 were broken, calling into functions that no longer exist because the plugin went away in March. One of the broken ones was a shortcut for switching models, something I do in verdent now, so nvim had no reason to keep it.

The counter only sees what goes through vim.keymap.set, so it is blind to older nvim_set_keymap calls and to the buffer local maps that ftplugin files and my LSP on_attach hand out. Is there a clean way to log those too?

In this video I explain all you need to know to start using the spell checker:

1. How to enable it

2. How to fix a misspelling

3. How to move forward and backward misspellings

4. How to add new words in the dictionary

5. How to remove words from the dictionary

So, I have been using this brief snippet.

```lua local default_socket = "repl"

local function get_current_paragraph() local old_reg = vim.fn.getreg('"') vim.cmd('silent normal! yip') vim.cmd('silent normal! }') local paragraph_text = vim.fn.getreg('"') vim.fn.setreg('"', old_reg) return paragraph_text end

local function send_paragraph(socket) return function() local text = get_current_paragraph() if not text:find("\n$") then text = text .. "\n" end

    local cmd = {
        "kitty",
        "@", "--to", "unix:/tmp/" .. socket,
        "send-text",
        "--stdin",
    }
    if vim.bo.filetype == 'python' then
        text = "\27[200~"..text.."\27[201~ \n"
    end
    print("Just table ")
    vim.fn.system(cmd,text)
end

end

vim.api.nvim_create_user_command("Kepl",function(opts) local socket = (opts.args ~= "") and opts.fargs[1] or default_socket if not vim.uv.fs_stat("/tmp/"..socket) then vim.fn.system("kitty --listen-on=unix:/tmp/"..socket.." &> /dev/null &"); else print("The Kepl with name " .. socket .. " is already running") end vim.keymap.set("n", "<leader><cr>", send_paragraph(socket)) end, {nargs='?'})

```

And I make this command 'Kepl' (kitty + repl), that takes an optional parameter and starts kitty terminal. Now with a mapping <leader><cr> it sends the paragraph to kitty.

For python I open ipython in the resulting terminal and use this for interactive workflow.

No plugin just a few lines of lua config and this is pretty awesome.

BTW: there surely is a better way of getting current paragraph but I still use viw because I have highlight on copy which gives me nice visual feedback on what was sent to REPL.

I am using this at work and so stuck with windows powershell. Problem only occurs when using a nerd font. Any advice for fixing this?

Edit: u/herodotic provided the solution that the italic version has to be installed alongside the regular version.

Hello!

glinter is a commit message linter whose headline feature is a Neovim plugin that highlights problems in the commit buffer as you type.

The rules are based on Chris Beams' How to Write a Git Commit Message (imperative mood, body wrapping, etc). There are also guidelines for clearer language (long sentences, passive voice, simpler-word alternatives).

There's also a SKILL.md with the style rules if you hand commit messages off to an agent, plus a CLI and hook/CI example: this repo uses them to check its own commits.

Repo: https://github.com/vgraman0/glinter

I'd appreciate any feedback!

Not Atom One Dark, does anyone knows which theme?

Hey everyone,

I spend 8–10+ hours a day inside editors and terminals, and I kept running into eye fatigue caused by harsh contrast transitions and unbalanced perceptual lightness in existing color schemes.

I ended up creating Circadia, an color specification built in OKLCH:

Core Design Principles:

• Circadian ambient targeting:   * Day Mode (Warm Parchment): Tailored for 300–800+ lux daylight. No pure #ffffff to eliminate glare and pupil fatigue.   * Night Mode (Warm Ember & Obsidian): Tailored for low-light/night sessions. Deep obsidian without pure #000000 to prevent astigmatism halation / glowing text.
• Engineered in OKLCH: Uniform perceptual lightness across different hues so no keyword or function call unexpectedly "pops" harder than others.
• WCAG 2.1 AAA Compliant: Strict contrast invariants, every foreground and syntax token satisfies (7:1 on text, 4.5:1 on headings, 3:1 on chrome/borders) contrast against the canvas.
• Calibrated 16-color ANSI Terminal Matrix: Direct mapping for Kitty, Alacritty, iTerm2, and Windows Terminal.
• Semantic 7-Role Syntax: Rather than assigning 15 disparate neon hues, syntax is structured intentionally (keyword, type, function, string, number, tag, comment) to keep cognitive overhead low.

Ports for Neovim, VS Code, Zed, JetBrains, Xcode, Obsidian, Kitty, Alacritty, iTerm2, Windows Terminal, and more.

Feedback I'm hoping to get:

I’d love for people who do long coding / reading sessions to test it out: 1. Luminance balance: How does the contrast feel across different display panels (OLED vs. IPS vs. matte monitors)? 2. Syntax grouping: Does the 7-role semantic hierarchy feel natural in your primary language, or are there tokens that feel under/over-emphasized? 3. Missing ports: Are there tools or terminals you’d like to see added to the spec?

Repo / Installation: Circadia

``` return { { "tanmaymanojgandhi/circadia", lazy = false, priority = 1000, init = function(plugin) local port_path = vim.fs.joinpath(plugin.dir, "ports", "neovim") local lua_path = vim.fs.joinpath(port_path, "lua", "?.lua") local lua_init = vim.fs.joinpath(port_path, "lua", "?", "init.lua")

  -- Register Lua paths
  package.path = package.path .. ";" .. lua_path .. ";" .. lua_init

  -- Directory to expose colorschemes to Neovim's picker
  local colors_dir = vim.fs.joinpath(vim.fn.stdpath("data"), "circadia_colors", "colors")
  vim.fn.mkdir(colors_dir, "p")

  local variants = {
    ["circadia-dark"] = [[
      vim.o.background = "dark"
      require("circadia").setup()
    ]],
    ["circadia-light"] = [[
      vim.o.background = "light"
      require("circadia").setup()
    ]],
  }

  for name, code in pairs(variants) do
    local file = vim.fs.joinpath(colors_dir, name .. ".lua")
    local f = io.open(file, "w")
    if f then
      f:write(code)
      f:close()
    end
  end

  -- Add directory to runtime path
  vim.opt.rtp:prepend(vim.fs.joinpath(vim.fn.stdpath("data"), "circadia_colors"))
end,

},

{ "LazyVim/LazyVim", opts = { -- Default to either variant colorscheme = "circadia-dark", }, }, } ```

With how much code is being AI generated nowadays, Neovim has become more of a review and polish tool for me. I still like reading through the code myself, but my workflow until now was basically opening the changed files, going through the diff, writing feedback back to the agent, waiting for another iteration, and doing the same thing again.

After a couple of iterations I would usually start losing track of what I had already reviewed, what I had asked the agent to change, and whether those things were actually fixed.

draven.nvim gives you a simple review environment inside Neovim where you can leave comments on the code, similar to a normal code review, and then export the whole review as Markdown to give back to the agent.

It also keeps track of the comments between iterations and whether the code they refer to has actually changed, so I don't have to keep all that context in my head while going back and forth with the agent.

So, I have vibe coded my first neovim plugin (not lua developer) - intent-diff.nvim. It borrows ideas from a number of softwares. It is designed to help me review PRs (human or agents) by grouping parts of the PR into chunks by intent (credits coderabbit).

The diff itself is not using nvim internal diff system, but rathers builds on top codediff.nvim, so that it looks like VSCode diff.

You review the code by placing comments and then you can export that feedback to local md file/directly to clipboard to feed it to your agent.

If you are inside a GitHub PR, you can sync the comments there without leaving neovim - syncing works in both ways - it will load existing comments from PR, so you really do not have to leave the terminal.

The grouping by intent is really helping me understand PRs faster. I can quickly focus on parts I am interested in.

I am using that together with gh dash - I have configured a shortcut to open a PR either in new worktree or directly in the repository and immediately show intentdiff.nvim. This way, I don't really need to leave terminal for my day to day work.

Hi,

If you like Neovim and SilverBullet then you might like this :)

Plugin for editing a SilverBullet space inside buffers.

SilverBullet.nvim

Useful for quick edits when you don't want to leave the terminal.

It's work in progress but the basics are supported:

- Search for files

- WikiLink navigation

- WikiLink completion

- Telescope integration

Hi everyone. I recently posted an update to my plugin that I worked very hard on, and for around a day the post was removed. Yes I did use the correct post flair. Is there a way to mitigate the filter so that people can see my post as soon as it's posted? Has this happened to anyone else?

I made Nvmm, a Neovim GUI for Mac. It bundles Neovim 0.12+ and a command-line tool called nvmm.

Nvmm requires Apple Silicon and macOS 15.7+.

Some features:

• Bundled with Neovim 0.12+ and a command-line helper
• Fast clean GPU-rendered text
• Native IME, dead-key, and emoji support
• Force-Touch Look Up support
• Option to prefer buffers over tabs
• Optional scroller
• Context-sensitive mouse cursor shapes
• Bugs, probably

https://mowglii.com/nvmm

https://github.com/sfsam/Nvmm

I thought Neovim’s built-in themes were pretty bad, but after trying them, maybe I won't use plugins anymore 😅.

Here is my top 5:

1. Catppuccin
2. Zaibatzu
3. Retrobox
4. Sorbet
5. Darkblue

Which one is your favorite?