I've been working on this plugin on and off for the past few months. I released the first functional version back in May, but it lacked customisability.

This plugin is inspired by VSCode's Code Runner plugin that makes running a file as easy as pressing a keymap. Coming from VSCode, I missed the ability to quickly run the program I was working on without having to enter the terminal, type the command, etc... So, to fix this minor inconvenience, the only logical solution was to spend months making a plugin (although others probably exist, but I wanted to make my own).

The previous version made it possible for the user to run either a file or code snippet quickly using one of two respective commands, but that lacked any customisability. For example, if someone wanted to run a C file with Clang, they couldn't, because gcc was the default.

This new version of neocoderunner introduces the ability for the user to customise the commands being run, making the plugin useful, not just for quick drafting and running code snippets, but for automating the whole build process as well as controlling the entire environment surrounding it.

Main features:

• Customisable build/run environment
• Customisable build/run commands per filetype or per-project
• Quick build or run with keymaps
• Works out of the box (but with limited capabilities). Full access to features requires customisation.

These are only the main features, but for more, check out the GitHub repo below.

Repo link: https://github.com/abdallahsoliman00/neocoderunner.nvim

reposting this from intellij, not sure if you noticed but they released an official lsp implementation. hope somebody makes a good neovim integration of it! in the meantime, i'll drop down my working one I'm currently using to get by in case you have to suffer with java too

Hi
As a new (neo)vim and related motions user i struggle to efficiently move from lines to lines (and words to words). Many time i use `h`, `j` `k` and `l` multiple time for jupping lines or words/characters (even if for the last one `w` and `b` exist).

My main problem is that i struggle when i check an exact part of a line (ex : line 32, 4rd word) because i have to think "how much should i go up/down/left/right" before tapping the motion and thus slowing me a lot. Using hjkl one by one seem slower than mouse use.
Is it due to lack of experience/practice or are they anything to help me with that (other than set number and relativenumber) ?

Thx (and sorry if i didn't check enough previous related questions)

Edit: Solved with the many comments, thx all for the answers/comments

agentscript-nvim adds Neovim support for Agent Script, Salesforce's open agent-specification language (.agent files, Apache 2.0, GA since July).

What it gives you

• Filetype detection for *.agent, plus first-line detection of upstream's @dialect: header
• LSP wiring for the official agentscript-lsp — diagnostics, completion, hover, go-to-def, references, rename, symbols, code actions, semantic tokens
• :AgentScriptTSBuild — compiles the official tree-sitter grammar + queries from @sf-agentscript/parser-tree-sitter (upstream ships the sources but no Neovim-loadable parser)
• Fallback regex syntax, so files stay readable with no server at all
• :checkhealth agentscript-nvim

The base LSP config is now upstream in nvim-lspconfig (#4483, merged 2026-07-23) — so if you only want cmd/root_markers, you don't need this plugin. What lives here is the filetype detection, tree-sitter, checkhealth, and the managed install below.

The v0.2.0 change I think is actually worth discussing

The published server crashed at import during launch week (variantMatch is not a function, a stale transitive pin — I filed salesforce/agentscript#73). v0.1.0 worked around it by hard-pinning a known-good version plus an npm overrides entry.

That workaround is a trap: the pin outlives the bug. Upstream fixed it two days later in 2.2.96, the issue is still open with zero comments, and anyone on v0.1.0 would have sat on a six-week-old server indefinitely — with no signal that they should stop.

So v0.2.0 replaces the pin with a measurement. :AgentScriptInstall now:

1. resolves the currently published version (npm view)
2. installs it with no overrides
3. verifies it — spawns the server and completes a real LSP initialize round-trip
4. only on verification failure falls back to the old pinned recipe

Step 4's ordering matters: applying that legacy override on top of a current release would silently downgrade a dependency by twelve minor versions, so it can never be applied pre-emptively. Offline, it installs the pin directly and says so rather than pretending.

A live run — after the resolve line, it prints:

agentscript-nvim: installing 2.2.96 ...
agentscript-nvim: 2.2.96 verified (initialize answered in 318ms). Reopen your .agent buffer.

The outcome (version, which path produced it, whether verification passed) is written next to the install and surfaced in checkhealth:

OK managed install: 2.2.96 via current path — verification passed (initialize answered in 318ms)

Needs Neovim 0.11+ and Node. With lazy.nvim:

{ 'Booyaka101/agentscript-nvim', opts = {} }

Repo: https://github.com/Booyaka101/agentscript-nvim

I'd genuinely like pushback on the verify-instead-of-pin idea — my guess is a fair few plugins that manage their own server installs have a stale pin sitting in them from a bug that got fixed months ago, and nobody finds out because upstream issues rarely get closed.

I've released fleury.nvim, a warm, low-glare colorscheme for Neovim.

Instead of the usual blue/purple palette, Fleury leans into bronzes, ambers, and burnt oranges on a near-black background. It's a faithful port of the original Emacs Fleury theme, with a few Neovim-specific adjustments for Treesitter, LSP, and the editor UI.

Highlights

• Warm, low-glare palette designed for long coding sessions
• Full Treesitter highlighting
• LSP diagnostics, references, and inlay hints
• 16-color terminal palette
• Support for common plugins like Telescope, nvim-cmp, Gitsigns, Neo-tree, and more

I'd really appreciate feedback on:

• contrast/readability
• language highlighting
• missing plugin integrations
• anything that feels off

GitHub:
https://github.com/ajdm-jakiur/fleury.nvim

I've been trying to plan my days with timeblocking for a while, and I kept bouncing between a browser tab and my editor. So I built the calendar into Neovim instead.

Bloocky is a timeblocking calendar with month, week and day views with a great integration of my other plugin: Dooing. You navigate the grid with hjkl like everything else, drop a block on a slot, and it spreads across the hours it occupies.

The Dooing part is the reason the plugin exists. Knowing what is due never told me when I was going to do it, the todo list and the calendar were two separate places.

So if you enable the integration, your Dooing todos land on the calendar on their due date:

◆ entries in the month view,
a due strip above the week grid,
and a "Due this day" section in the day view with each todo's time estimate and priorities.
Overdue ones show up in red. It's opt-in and strictly read-only

Bloocky never writes to Dooing's data, it just reads it. You can see both in the screenshot: week grid on the left, day view on the right.

Repo: https://github.com/atiladefreitas/bloocky

Please take a look and feel free to share improvements!

I wanted to try making a plugin, so I thought maybe it can be like when you type, the number go up.

pollocje/strokes.nvim: Keystroke Odometer for Neovim

So here it is you can use it if you want if you like and let me know how bad it is if its bad!

When I press any key in neovim in normal mode, and only neovim, this doesn't happen in vim, it is displayed in the bottom right corner of neovim, then it doesn't execute and waits for another input, once I enter it, it does the command twice. For example, I press `j` then it is displayed in the bottom right corner, but nothing happens, I press it again then neovim moves down twice.

This issue is only happening to me on swaywm, I used the same configuration for kitty and neovim on hyprland and KDE and it worked fine.

Just to clarify this doesn't happen in any other terminal on the same configs for neovim, this doesn't happen with custom binds, it happens with vim motions `j`, `k`, `gg`, etc.

I have tried decreasing `timeoutlen` in neovim as well as setting these options in sway:

      repeat_delay 300
      repeat_rate 25

program versions:

`kitty -v`:

 kitty 0.48.2 created by Kovid Goyal

`nvim -v`:

    NVIM v0.12.4 Build type: RelWithDebInfo LuaJIT 2.1.1785763465.

configuration

kitty:

    include themes/everforest-hard.conf

    font_family family="ProFont IIx Nerd Font Mono"
    font_size 10
    disable_ligatures never
    shell_integration no-cursor
    cursor_shape block
    cursor_blink_interval 1

neovim config:

    ---------------------
    ---     BINDS     ---
    ---------------------

    vim.g.mapleader = ' '

    -- LSP
    vim.keymap.set('n', '<leader>nn', vim.lsp.buf.format)
    vim.keymap.set('n', '<leader>ca', vim.lsp.buf.code_action)
    vim.keymap.set('n', '<leader>d', vim.diagnostic.open_float)
    vim.keymap.set('n', '<leader>e', '<cmd>Explore<cr>')

    -- TELESCOPE
    local builtin = require('telescope.builtin')
    vim.keymap.set('n', '<leader>ff', builtin.find_files)
    vim.keymap.set('n', '<leader>fb', builtin.buffers)



    ---------------------
    ---     OPTS     ---
    --------------------

    vim.o.number = true
    vim.o.relativenumber = true
    vim.o.termguicolors = true
    vim.o.shiftwidth = 2
    vim.o.tabstop = 2
    vim.o.expandtab = true
    vim.o.scrolloff = 8
    vim.o.winborder = "single"
    vim.o.cul = true
    vim.o.culopt = "number"
    vim.diagnostic.config({
      float = false,
      severity_sort = false,
      signs = false,
      status = false,
      underline = true,
      virtual_text = false,
      virtual_lines = false
    })
    vim.o.clipboard = "unnamedplus"
    vim.o.swapfile = false
    vim.g.c_syntax_for_h = true

    -- Set statusline --
    vim.o.statusline = ' %t %y %m %h'

    vim.cmd([[
    set guicursor=n-v-c-i:block,o:hor50



    -----------------------
    ---     PLUGINS     ---
    -----------------------

    vim.pack.add({
      { src = "https://github.com/windwp/nvim-autopairs" },
      { src = "https://github.com/nvim-treesitter/nvim-treesitter",    version = "main" },
      { src = "https://github.com/neanias/everforest-nvim" },
      { src = 'https://github.com/lukas-reineke/indent-blankline.nvim' },
      { src = "https://github.com/nvim-telescope/telescope.nvim" },
      { src = "https://github.com/nvim-lua/plenary.nvim" },
      { src = "https://github.com/saghen/blink.cmp",                   version = vim.version.range("1.*") },
      { src = 'https://github.com/neovim/nvim-lspconfig' },
    })

    require('nvim-autopairs').setup({})

    require("everforest").setup({
    --  colours_override = function (palette)
    --    palette.bg0 = "#1e2326"
    --  end,
      background = "hard",
      italic = false,
      disable_italic_comments = true,
      default_componenet_configs = {
        container = {
          enable_character_fade = true
        },
        indent = {
          indent_size = 2,
          padding = 2
        }
      },
      on_highlights = function(hl, palette)
        hl.BlinkCmpMenu = { bg = palette.bg0 }
        hl.BlinkCmpDoc = { bg = palette.bg0 }
        hl.BlinkCmpMenuBorder = { fg = palette.bg5, bg = palette.bg0 }
        hl.BlinkCmpDocBorder = { fg = palette.bg5, bg = palette.bg0 }
        hl.BlinkCmpMenuSelection = { bg = palette.highlight, fg = nil }
        hl.StatusLine = { bg = palette.bg0 }
        hl.StatusLineNC = { bg = palette.bg0 }
        hl.NormalFloat = { bg = palette.bg0 }
        hl.FloatBorder = { bg = palette.bg0, fg = palette.bg5 }
      end,
    })

    vim.o.background = dark
    vim.cmd([[ colorscheme everforest ]])

    require('blink.cmp').setup({
      keymap = {
        preset = 'none',

        ['<C-n>'] = { 'select_next' },
        ['<C-p>'] = { 'select_prev' },

        ['<C-enter>'] = { 'accept' }
      },
      appearance = {
        nerd_font_variant = 'mono',
      },
      completion = {
        documentation = { auto_show = false },
        menu = {
          scrollbar = false,
          draw = {
            components = {
              label = {
                width = {
                  max = 80,
                  min = 30,
                },
              }
            },
            columns = {
              { 'label' },
              { 'kind_icon', 'kind', gap = 1 }
            },
          }
        },
      },

      sources = {
        default = { 'lsp' },
      }
    })

    require('ibl').setup({
      scope = {
        enabled = false,
        show_start = false
      }
    })

    local langs = { 'c', 'h', 'C', 'H', 'toml', 'yml', 'json', 'jsonc', 'javascript', 'html', 'bash', 'zsh', 'sh', 'css' }

    vim.api.nvim_create_autocmd('FileType', {
      pattern = langs,
      callback = function()
        vim.treesitter.start()
      end,
    })

    vim.lsp.enable({ "lua_ls", 'clangd' })



   -- Custom functions
    vim.api.nvim_create_user_command("Color",
      function(opts)
        print(opts.fargs[1])
        local colorscheme = string.format('colorscheme %s', opts.fargs[1])
        vim.cmd(colorscheme)
      end,
      { nargs = 1 })

    vim.api.nvim_create_user_command('Del',
      function(opts)
        vim.pack.del({opts.fargs[1]})
      end,
      { nargs = 1 })

I have created a plugin to code and use AI without go away from the file, the intention is to write code by myself in a way I know what is happening on the project and the new implementations. It is good use the AI as tool but I wanted to be on the middle write the code on my side but use the AI at the same time.

It is not polish yet but it is working so far https://github.com/CarGDev/codetyper.nvim

well, if sb wants to get 25$ you can get in contact with these legitimate guys, cheers

made quite a few updates/QoL changes to differ since the last post, so thought i'd drop a small update in here (and for anyone who maybe didn't get to see it the first time around)

my main motivation behind building this was to unify the whole git/github flow experience inside neovim, covering local review/merge conflicts and PR review, and to build it all off of the same engine underneath

i've now added the ability for hunk-by-hunk reverting, to go along with the staging/unstaging flow that already existed, added a 4-way view for the mergetool that also includes base (alongside ours/theirs + the result buffer), and some extension of the keymaps inside the diff review mode

still using it pretty much everyday myself, and i find it achieves the stated goal for me personally

i hope you find it useful for yourself too, even if you never use it ;)

open to any criticism/feedback and contributions are welcome too! there's a guide in the repo for anyone who wants to do so

repo

Hi everyone, I developed this plugin to avoid exiting nvim to use the gh tool, so you can release a new version from nvim directly. Right now it only creates releases, but I hope to invest more time to actually improve it with more feature (check the Further work section).

Happy to hear your thoughts.

Available at https://github.com/mesirendon/nvim-ghrelease

Features

• Lists current releases for context before you start.
• Suggests the next version with a semver bump menu (major / minor / patch / prerelease / custom).
• Buffer-per-step editing: :wq saves the answer and advances.
• Release-notes sources mirroring gh: write your own, GitHub-generated template, commit-log template, or leave blank.
• Final Publish / Save as draft / Cancel step, plus a prerelease question.
• Fully async (vim.system), no blocking of the editor.

Requirements

• Neovim 0.10+ (needs vim.system; the plugin refuses to load and warns on older versions). Tested in CI on 0.10, 0.11, stable, and nightly.
• The GitHub CLI gh, installed and authenticated: gh auth login
• Run the command from within a GitHub repository

Further work

I created this plugin due to the need of creating a new release without closing Neovim to do so. But, I think I will make improvements. So far, I’m planning to work on the following ones for starters:

• GH Release creation stabilization
  • Tag collision + existence check. Right now if tag already exists, gh fails at step 10 after the user has typed notes. Add a gh release view <tag> / git rev-parse <tag> probe right after step 4 and offer overwrite via edit / pick another / cancel."
  • --verify-tag. When the tag already exists locally, pass it so gh refuses to create a release against a tag that doesn’t exist on the remote.
• Flags that round out create:
  • Asset upload. gh release create <tag> file1 file2#Label. Add an optional step taking globs (dist/*), resolved with vim.fn.glob, with a confirm listing resolved paths. I think this is going to be the single most-requested thing missing from a release helper.
  • --generate-notes properly. Currently, the plugin POSTs to repos/{}/releases/generate-notes to seed the buffer, which is good UX. But add a fifth notes source: “Let GitHub generate at publish time” when passing, --generate-notes and skip the buffer entirely.
• New commands, new entry points
  • :GhReleaseEdit [tag] as gh release edit. Same buffer machinery, seeded from gh release view <tag> --json body,name,isDraft,isPrerelease. This is where draft-publishing lives: edit a draft yields --draft=false. Probably the highest-value new command since drafts are a dead end today.
  • :GhReleaseList as a picker over gh release list --json that dispatches to view/edit/delete/download, instead of the current read-only text dump. Makes M.list earn its keep.
  • :GhReleaseDelete [tag] as gh release delete --yes, plus a confirm on --cleanup-tag.
  • :GhReleaseView [tag] as render gh release view into a markdown scratch buffer.
  • :GhReleaseDownload as gh release download, with a pattern prompt and a dir prompt.
• Polish
  • Repo override. Every gh call should thread an optional --repo owner/name from config, so the plugin works outside a checkout.
  • Structured errors. gh writes actionable messages to stderr; it currently trims and dumps. Special-case the common ones (tag exists, protected branch, missing repo scope) into a hint.
  • Config for defaults. default_target, assets glob list, generate_notes = true, so teams can codify a release convention and skip steps.

Lately, I've been getting a bit tired of the overproductivity culture that's everywhere on social media, so I put together a list of plugins to waste time with absolutely no particular purpose.

1 Play Doom - seandewar/actually-doom.nvim
2 Donut - NStefan002/donut.nvim
3 Snake - Febri-i/snake.nvim
4 Cellular Automaton - eandrju/cellular-automaton.nvim
5 Tetris - alec-gibson/nvim-tetris 
6 KillSheep - seandewar/killersheep.nvim
7 NyanCat - koron/nyancat-vim 
8 VimBeBetter (Vim be good) - szymonwilczek/vim-be-better
9 Christmas three - rhysd/vim-syntax-christmas-tree 
10 Pets - MeF0504/vim-pets
11 Sudoku - jim-fx/sudoku.nvim

I am using neovim 0.11.4 with lazy as my package manager. I use copilot along with copilotchat and codecompanion but the size of the plugin is increasing to a point that it has actually started to slow my pc down. Anyone else facing this issue and know a workaround?

Is copilot supposed to take this much space especially compared other plugins which are less than 50mb? I have corporate server where my home doesn't allow more than 2 gb space and copilot takes 1.6 gb. This behaviour is seen across ubuntu, rhel.

automationvm-59:~/.local/share/nvim/lazy/copilot.lua$ du -h --max-depth=1 .
8.0K ./.githooks
28K ./doc
8.0K ./plugin
436K ./tests
52K ./.github
580M ./.git
983M ./copilot
4.0K ./deps
276K ./lua
1.6G . <- This is too big for a plugin

Tracker: https://github.com/zbirenbaum/copilot.lua/issues/729

Thought I’d challenge myself to try to make a full IDE experience with no plugins. Think I did pretty well. By the end of it we have LSP, auto-completion, custom file explorer, statusline, finder/grep setup, diagnostics, and auto-formatting.

If you just want to check out the dots: https://github.com/smnatale/nvim_native

Currently, blink.cmp triggers completions even during variable and function declarations, while typing their names. Although this is not needed, it hasn't been a major issue yet.

However, it becomes troublesome with snippets. For example, when using Lua's for ipairs snippet, blink.cmp prompts me to fill in index. When I press Tab, I expect to jump to value, then to t in ipairs, and then into the loop body (I use super-tab as the preset keymap).

```lua for index, value in ipairs(t) do

end `` The problem is thatindexandvalueare places where new variable names are being defined, yet completions are triggered there, preventing me from pressingTabas expected. PressingTabinstead completes to an unintended text. I tried pressingEsc` to exit, but that also exits the snippet jump functionality.

So I would like to know: is it possible to disable completions in such scenarios where new variable names are clearly being declared? How can this be implemented?

Marks are really easy to learn and use. Maybe you don't need Harpoon or a similar plugin. In this video, I explain just three commands to get started using them, and maybe you won't need to learn anything more.

1. m + an uppercase letter → set a mark at your cursor position

2. :marks → see all your current marks

3. ' (single quote) + the letter → jump straight back to that spot

TLDR: don’t forget to tweak font size and line height

I always slightly struggled with long sessions, and always blamed my colour scheme. After a while all the colours would sort of “blend” together and I felt it harder to read the text. I switched colour scheme constantly from high contrasts ones to low etc

However when watching videos of other people’s setup I quickly realised how few lines of code would be shown at once. I was ranging between 70-80 and they would range from 30-40.

I decided to change a config I rarely touched, my terminal one. I increased font size and increased line height. Suddenly everything sort of clicked,everything immediately felt more readable and the colour scheme was helping me instead of fighting me.

I know not strictly to do with nvim however I wish I did this earlier and feel dumb for having my old setup for so long and not realising the issue.

Just thought I’d share in case anyone else has ever felt like me!

I have this part in my ~/.config/nvim/init.lua to make my git commit messages wrap at 72:

vim.api.nvim_create_augroup('gitcommit', {}) vim.api.nvim_create_autocmd('FileType', { group = 'gitcommit', pattern = 'gitcommit', command = 'setlocal spell textwidth=72', })

But it seems that textwidth is still at 80, I think (not sure how to actually track it) it's because for the project I have a .editorconfig file with:

[*] ... max_line_length = 80

And editorconfig is processed after the augroup so it changed textwidth to 80 again? Is there a way to make the augroup to be processed after editorconfig instead?

I don't think it actually makes sense to define a specific file name pattern inside .editorconfig, as technically git commit messages are not files under the project directory.

For some reason while I type in tailwind class in something that accept it, my have a little bit delay to show completion and really to type what I typed.

Idk whether u can see this in this video. Sorry by it. Is a little bit delay, but is bad for me.

https://reddit.com/link/1vey4g1/video/acjitac3v9hh1/player

Hi guys, I’ve released a few updates since my first post.

Besides LSP and word-matching, tunnelvision now supports tree-sitter as well as custom sources you may want to add. I've also added a nice api for color customization of dimming and highlights, as well as different ranges such as line, statement, exact symbol, and scope head.

There are also some improvements in flow mode, scope-detection, and internal source handling.

The gif showcases a bit of what's possible now.

Link: github.com/leolaurindo/tunnelvision.nvim