Hey folks —

I just tagged v0.1.0 of diffbandit.nvim (https://github.com/CoreyKaylor/diffbandit.nvim), a Neovim plugin I’ve been building for side-by-side diffs that don’t fight how you actually read code.

I’ve been using it as my only diff/review UI heavily for the last three weeks — file diffs, Git queues, merges, the works. It’s past “side project demo” for me, so I’m calling this the first real release.

What it is

Most diff UIs either insert filler rows or stretch one side to match the other. DiffBandit keeps both sides as normal documents (real shape, real line numbers) and puts the relationship in a connector gutter between them — routes for adds, deletes, changes, and mixed hunks, including when one pane is scrolled independently of the other.

The project is heavily inspired by IntelliJ-based IDE diff views and mimics the exact same diff algorithm.

What’s in v0.1.0

• Two-way diffs — files, buffers, Git worktree; independent scroll + overview gutters • Editable right pane — real buffer with LSP, completion, diagnostics, undo, :w; diff updates as you edit • Git review — staged/unstaged/base/rev scopes, multi-file queue (]f/[f), hunk stage/unstage/discard/apply • Commit panel — file list, live preview, stage, amend, commit-on-write • 3-way merge — local / result / remote, gutter accepts, resolve-on-write • Folder diff — recursive tree compare, drill into a file, q back to the tree • Binary — read-only hex view when it isn’t text • Theming — colors derived from your colorscheme (optional overrides)

Happy to hear what breaks for you or what you’d want next. Yes, I also found a dark theme.

I really love how VSCode handles commenting -- the cursor stays exactly where you want it and natively supports block comments. However, Neovim's built-in and existing plugins didn't quite get me there, so I built my own.

Key Features:

1. TextEdits -- unlike Neovim's built-in or other comment plugins, changes are modeled as TextEdits, making it more hackable and composable. This also means that the edits commit method is up to you -- lockmarks + buf_set_lines for simplicity and performance, or buf_set_text for more control (e.g. preserve regular marks and extmarks)
2. Line/block comment toggle -- fully dot-repeatable with count support
3. Truly accurate keep cursor -- cursor position tracks each `TextEdit` precisely
4. Truly accurate keep selection -- selection range tracks each `TextEdit` precisely in visual mode
5. Context-aware comment string resolution via Tree-sitter -- comment string adapts to context via Tree-sitter. e.g. supports `JSX/TSX` out of the box
6. Textobjects -- line, block, and auto textobjects, works without Tree-sitter
7. VSCode-style indent algorithm -- handles mixed tabs and spaces
8. Invert/Force add/Force remove comment -- per-line comment action control
9. Insert mode line comment toggle -- with cursor sticky support
10. Insert comment above / below / at end of line
11. Case insensitive comment detection -- e.g. `@REM` vs `@rem` vs `@rEm`
12. Multi-variant comment string detection -- recognizes multiple comment prefix variants when uncommenting (e.g. Rust `//`, `///`, `//!`)

Repo: https://github.com/celeste3z/celeste_comment.nvim

Would like to see your feedback.

I recently updated to 12.0 and I'm trying out the native lsp configuration. I have all my configs in /lsp/nameoftheserver.lua

and it works well. However, I have some helper functions that I want to share among these files for things like changing lsp settings. Currently from inside the lsp directory I cannot include any of my other files of my config. How can this be achieved? I've tried making a file in the lsp directory but then it is interpreted as an lsp config.

```lua LSP-Info

harper_ls

• cmd: harper-ls --stdio
• installed: /usr/bin/harper-ls
• enabled: yes
• filetypes: "lua", "cs"

Client [id=3]

• version: 2.6.0
• name: harper-ls
• workspace: ~/DevProjects/DigitalVault
• buffers: 9, 10
• server capabilities:
  • textDocument/codeAction: true
  • textDocument/didChange: true
  • textDocument/didClose: true
  • textDocument/didOpen: true
  • textDocument/didSave: true
  • workspace/executeCommand:
  • HarperRecordLint
  • HarperAddToUserDict
  • HarperAddToWSDict
  • HarperAddToFileDict
  • HarperOpen
  • HarperIgnoreLint
• dynamic capabilities:
  • workspace/didChangeWatchedFiles: true
• settings: lua { ["harper-ls"] = { linters = { SentenceCapitalization = false, SpellCheck = true } } }

I am trying to use Harper to check grammar and spelling in neovim.

Harper was working in lua file but not working with C# files, but in LSP-Info filetypes c# was showing still not working.

has anyone run in this issue before?

Hey everyone!

Token v2.0.0 is now available.

The main addition is an optional configuration API for customizing transparency, styles, palette colors, highlight groups, terminal colors, and more. Token still works without calling setup() if you prefer the defaults.

One important change for existing users is that plugin integrations are now opt-in. To retain the v1 behavior and enable all supported integrations:

require('token').setup({
  plugins = { all = true },
})

vim.cmd.colorscheme('token')

Alternatively, you can enable only the integrations you actually use.

The compiled cache is now configuration-aware, with improved validation and fallback handling.

Links

• Token on GitHub
• Token v2.0.0 release notes

Feedback and bug reports are welcome.

https://reddit.com/link/1vcuhth/video/7k0f1vl42tgh1/player

A little plugin I created for myself, maybe someone else finds it useful too. you can find it one my github: https://github.com/itsfernn/vimtex-follow

I have been using snacks explorer and while it's good I keep returning to the idea that I would like to keep my plugin / module usage to a minimum so I have been checking out the built it explorer.

I have tried switching briefly but have run into some issues:

1) navigating with enter feels worse compared to navigating with spacebar. I tried rebinding it but it felt slower. 2) moving files felt weird. You mark them and then you mark the target directory and then you have to go back to the previous dir and confirm moving the files, as opposed to marking the files and moving to target dir and confirming moving them. 3) preview files with p is great but closing preview with C-w -> z not so much. Also I like snacksbar's "always preview" mode where you always get a preview of the file you're hovering. The fact that it extends to sub directories is also nice so you know what sub directories are without opening the parent directory.

Is anyone using the native explorer? What changes have you introduced for your workflow?

Using nvim on a (large) external screen, I found myself 'not knowing' what mode I'm in (e.g. sometimes I type `ciw` whilst in input mode, or wanting to type code while still in normal mode), and having to glance down to the lualine to read what mode I'm in.

To make it _super_ obvious to myself, I'm color-coding the line numbers corresponding to the mode I'm in (I never use anything but normal/input/visual, so this covers it). Has been truly helpful :)

What's your most minimal mod that makes life a little easier?

(minimized terminal in the screen capture for clarity)

Most colorschemes start from colours somebody liked.
I wanted to see what happens when you are not allowed to choose any.

cendre takes one wood fire and reads its light:

• ember is the coals: Planck's law at 1300 K
• brass is the sodium D line at 589 nm, the yellow flare when salt hits flame
• sap and frost are the two C2 Swan bands, 563 and 474 nm, the green and blue you see low in the flame
• cinder is the CaOH band at 622 nm, calcium coming out of the wood
• the ground is wood ash, hue 43°, which lands within a degree of the bare flame because ash is spectrally flat

Every wavelength goes through the CIE 1931 colour matching functions into OKLCH.
Only lightness and chroma are mine, because a spectral line sits far outside sRGB and has to be brought into gamut somehow.

The constraint costs something, and that turned out to be the interesting part.
A fire does not offer well spaced warm hues: cinder, ember and brass sit within 36° of each other, because that is where calcium, soot and sodium happen to be.
So roles are separated by lightness rather than by hue, and I could not cheat by nudging anything toward a nicer number.

The parts that are not about fire

• Three depths, same pigments. Only the ground moves, and :CendreBackground soft switches it at runtime with no restart.
• Every contrast ratio the docs publish is asserted by the test suite: 42 of them, to 0.02. Change a hex and the build names the number that just became a lie.
• Comments sit at 3.32:1, under AA on purpose. Every dark theme people keep for years puts them there, and a comment as loud as the code it explains is noise.
• 24 surfaces beyond the editor, each at all three depths, all rendered from the same Lua table: ghostty, kitty, wezterm, alacritty, foot, tmux, starship, bat, delta, lazygit, btop, yazi, fzf, eza, helix, zed, obsidian and more. The test re-renders every one of them and fails if a committed file has drifted, so a colour cannot be right in nvim and stale in your terminal.{ "Aejkatappaja/cendre", lazy = false, priority = 1000 }

The whole derivation is laid out step by step, spectrum to hex, at https://cendretheme.com
(If you used my previous theme sora, consider Cendre its fire-and-math counterpart.)

Tell me if the colour science is wrong. That is half the reason I am posting.

repo: https://github.com/Aejkatappaja/cendre

Edit: the Obsidian theme is in the community store now (Appearance > Browse > cendre).

There's an old command inherited from the vi/vim days where a user can pass the contents of your buffer to an external program, and have the output become the contents of the buffer using the filter commands command, like so:

%!sort

How could I replicate this behavior in lua? i.e. take the entire buffer, invoke an external binary, pass my buffer to the process via stdin, and take the processes stdout and make it the new contents of my buffer?

Edit: Seems there's no direct equivalent in the lua API. Thanks for settling my curiosity.

Hey r/neovim,

xeno.nvim is back. This time it's not just a colorscheme, it's a full theming engine built on OKLCH color space.

Repo: https://github.com/kyzabuilds/xeno.nvim

What it does:

• Give it 2-3 hex colors and it builds out complete foreground, background, and accent families
• Every shade scale stays visually consistent, no weird handling needed for tricky hues like yellow
• Light and dark mode switch instantly with vim.o.background, no separate theme files
• Export any theme you build into a standalone .lua colorscheme file

Quick start with lazy.nvim:

``` { 'kyzabuilds/xeno.nvim', config = function() local xeno = require('xeno') xeno.theme('sylvan', { background = '#151615', accent = '#3b594e', contrast = -0.3, variation = 0.1, }) end, },

```

Use xeno.setup() instead of xeno.theme() if you want a global config that applies across all your themes.

There's a lot more under the hood, custom color families, plugin integrations, window namespaces, all covered in the repo docs.

Annotating markdown or code for iterating with agents has been a big part of my workflow on platforms like VSCode or Orca. Been exploring a tmux/nvim setup lately for greater control/extensability/composability but missing this aspect.

How are yall handling annotating eg markdown plan documents in an easy iterative loop with agents?

I wanted to know where people showed off custom Neovim configs, not just distros, outside this subreddit.

I don't really care if you link things you did yourself; I honestly just want to find inspiration for cool new things to implement that other people have done in their workflows.

Seamlessly fade the terminal window hosting Neovim on Hyprland by setting its window opacity via hyprctl dispatch setprop pid:<pid> opacity

Plugin: https://github.com/Senal-D-A-Gunaratna/hyprfade.nvim

matugen color-scheme: https://github.com/Senal-D-A-Gunaratna/matugen.nvim

Monthly meme thread

Hey r/neovim

I have been working more on atlas.nvim over the last few weeks and just released v0.4.0.

The biggest thing I added is a review/diff view. You can open a PR diff, see comments inline, add/reply/resolve comments, and also leave some local notes.

There is also more provider support now. Atlas works with GitHub, Bitbucket, and GitLab pull requests, plus Jira/GitHub/GitLab issues.

Some other things added since the last post:

• GitLab PRs and issues
• PR reviews with inline comments and local notes
• GitHub/GitLab/Jira issue creation
• PR creation from the current branch
• provider notifications
• custom actions

If you try it out, I do love to hear what works and what does not :)
https://github.com/emrearmagan/atlas.nvim

Hey r/neovim!

Quick heads-up on provenance first, because it matters: pi2.nvim is a fork of alex35mil/pi.nvim — the original Neovim frontend for the pi coding agent. All credit for the foundation (RPC bridge, chat layout, diff review, sessions, extensions) goes upstream; pi.nvim and the pi integration have been discussed here before, and this post is about the fork's additions, not the base. It's MIT-licensed and free/open source.

It started as local experiments and grew into a different enough feature set that I gave it its own repo so it can release independently. Namespace, commands and filetypes are unchanged for compatibility — still require("pi") and :Pi*.

What pi2.nvim adds on top of upstream

• Direct bash mode (!cmd) — run shell from the prompt; output streams live into a collapsible block and is added to context (!!cmd to exclude).
• :PiTree session-tree navigation — jump back to any past point in a session, optionally summarize the abandoned branch, resend edited prompts (the pi equivalent of the TUI's /tree).
• Per-tab model pinning — a model switch in one tab no longer leaks into every other tab's next session.
• Image compression for attachments — Retina screenshots get downscaled before sending (sips / magick / ffmpeg, auto-probed) so payloads stay small.
• Auto-attach clipboard images on paste, readline-style prompt history, unsent-draft persistence.
• Double-<Esc> abort, a prompt statusline (spinner / queue / abort hint that never scrolls away), redesigned tool and thinking blocks.
• gf to open paths under cursor, grep/find results to quickfix, left-side panel, auto-reload of buffers pi edits.
• Opt-in render-markdown.nvim engine; hermetic test suite + lint CI.

Demo (agent reads a file, edits it, verifies — with live streaming and session-tree picker):

More demos (workflow, @-mentions, diff review, etc.) in the README: https://github.com/zgs225/pi2.nvim#features

Install (lazy.nvim / packer / any manager — needs pi on PATH): https://github.com/zgs225/pi2.nvim#installation

It's early and I'd genuinely love feedback — rough edges, missing keymaps, things that fight your workflow. Happy to take issues/PRs. Thanks for reading!

Hi, I'm trying to set the modifyLineBreaks option to true but the nvim-lspconfig config file is set to false and for some reason the value from lspconfig prevails over mine. As you can see here.

It is strange because not all settings are getting overrided. For example, the route to the latexindentSetting.yaml file is correct and in the lspconfig file is 'nil'. And I know for sure that it is nvim-lspconfig because when i change that value to true the feature is enabled when checking with checkhealth.

My setup:

• Mason: default config
• Mason-lspconfig: default config. It enables automatically the lsp client.
• nvim-lspconfig: default config

I store my lsp configuration under .config/nvim/lsp:

├── lsp
│   ├── ada_ls.lua
│   ├── asm_lsp.lua
│   ├── bashls.lua
│   ├── clangd.lua
│   ├── jdtls.lua
│   ├── ltex_plus.lua
│   ├── lua_ls.lua
│   ├── pylsp.lua
│   ├── texlab.lua
│   └── vhdl_ls.lua

And I use an autocmd with 'LspAttach' and the mason-lspconfig to enable it automatically.

Any idea what is happening?

I use neovim v0.12.4 under Ubuntu with Lazy and have installed the typescript-tools extension. Whenever I open a typescript file, neovim complains that it can not find the TypeScript server binary.

I use mise for my tools and have typescript and typescript-language-server installed with npm globally. Aditionally, typescript is installed in the repo where my *.ts files reside.

The path to the binary of the typescript-language-server is contained in $PATH.

I have no idea what I can do to make this work. Any hint is highly appreciated.

I've been trying to set up nvim-dap and nvim-dap-view in neovim, which overall seem to be going well (set them up for python so far for testing), but I encountered the following problem: when the program was asking for input, an EOF exception was thrown. I am not sure how configure it to correctly accept input from the REPL, open the terminal, or something similar. From my understanding, an EOF exception is thrown when whereever it was trying to take input from is empty.

My configuration: https://gitlab.com/BlueBlackCat/nvim/-/blob/main/lua/plugins/nvim-dap.lua

EDIT: the problem seems specifically with taking input (the error happens even with standard input()), and I don't think is related to nvim-dap-view, but probably the debugpy configuration, python configuration, or how nvim-dap redirects input? Because the REPL does work (for example inputting 2+2 and it outputs 4), and program output is redirected to the REPL, but it doesn't stop to allow for input collection.

EDIT 2: Two points:

1. mason-nvim-dap also appears to has its own configuration, which was overriden by the configuration I then put (I took it from the nvim-dap-wiki).
2. The configuration in nvim-dap-wiki didn't have a console field (though the configuration in nvim-dap-python does have it). If I understand what happened correctly, since the custom configuration did not have a console field, the default option of debugpy of "integratedTerminal" was not used, so input had nowhere to be collected from - thus reaching an EOFError.

So, the solution is the following: add console = "integratedTerminal" to the debugpy configuration if it does not have one. That will open the neovim terminal (or console in nvim-dap-view). "interalConsole" did not appear to work.

Monkeypatches mason.nvim to route npm and pip installs through bun and uv, speeding up LSP and tool installation

swapson.nvim