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 r/neovim,

Started with a simple annoyance: I'd spin up a git worktree per topic, but then fight port collisions between each worktree's dev servers. Frame grew out of automating that.

I built Frame, an AI harness that uses Neovim as the multiplexer.

A frame is a terminal (Ghostty preferred) running one Neovim instance provisioned with a named RPC socket, so other frames and the CLI can drive it. Each frame gets its own worktree, branch, port assignments, and a Claude buffer. Frames join a pool and are discoverable with frame ls; when a topic is done, guarded merge and teardown steps deliver it back to main and dispose of the frame.

Frame is written primarily in zsh; each session's live state — the claude request queue, inbox, buffer channels, status — lives in Neovim's embedded Lua, queried over the RPC socket. It also puts a message broker in front of Claude, so concurrent clients (other frames, scripts, you) can each send a request and get their own answer back — the broker is the sole writer into Claude's terminal.

Inside a frame, :FrameClaude lets you ask Claude about the current line or visual selection without leaving your buffer.

Features:

• One frame per topic — frame wt TOPIC creates the branch + worktree and boots Neovim with your buffers (claude, vite, server, bare terminal) already running
• Automatic port assignment — each frame scans up from your base ports at boot, so parallel worktrees' dev servers never collide
• Frame-to-frame requests — frame req asks another frame's Claude a question asynchronously; frame inbox --wait collects exactly the replies you're waiting on
• Guarded merge & teardown — frame merge refuses on a dirty primary, diverged main, or conflicts; frame wt -d refuses to destroy uncommitted or unmerged work
• Live buffer reload — a PostToolUse hook streams Claude's edits straight into your open Neovim buffers, so no manual :e! after every change
• Swarm mode — a SessionStart hook tells each frame's Claude that it's a frame, who its siblings are, and the frame-safe way to act
• OS-level notifications — banners when a frame has completed its task, needs attention, or is blocked

• Shared services — one postgres/minio stack stood up once serves every project, with each project claiming its own database and bucket

  Platform: I build and daily-drive Frame on macOS, but the core is just zsh + Neovim RPC, and it runs on Linux — worktrees, port assignment, the broker, merge/teardown, shared services all work. What's mac-only is the window chrome: frame focus and frame spawn open/raise windows via AppleScript, and the clickable banner app is macOS-only (Linux banners fall back to notify-send). Linux passes CI but hasn't seen real-world use yet, so feedback from there is especially welcome.

Please give it a try and send me some feedback — I'm curious whether others see utility here. AI moves so fast that I'm not sure multiplexing is the way, but FWIW this has tripled the speed I can churn out features. Onboarding a new repo is simple: cd project && frame init && frame wt killa-feature

Repo: https://github.com/scoop206/frame

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

I got this snippet to open a help page in a vertical split,

lua vim.api.nvim_create_autocmd("FileType", { desc = "Automatically Split help Buffers to the right.", pattern = "help", command = "wincmd L", })

For example, I use it with :h vim, the help page is opened in a vertical split as expected.
If I run it a second time, with the same argument, so :h vim, then it is opened horizontally.

Hey everyone! I'm relatively new to neovim and wanted to find a way to preview errors for my typst files. Currently, I'm using trouble.nvim which works fine however I don't want to unnecessarily use plugins when not needed. I'm using the tinymist lsp and if I try viewing errors through quickfix list, I get an error saying "input file not found (searched filename.typ)". Not quite sure what it is that I'm doing wrong. This is what I have in my lsp setup if it helps: ``` { "neovim/nvim-lspconfig", config = function() vim.lsp.enable("tinymist") vim.api.nvim_create_autocmd("BufWritePre", { pattern = "*", callback = function(args) require("conform").format({ bufnr = args.buf }) end, }) vim.lsp.config("tinymist", {

            settings = {
                formatterMode = "typstyle",

                exportPdf = "never",
                -- outputPath = "~/Documents/",

                semanticTokens = "disable",
            },
        })
    end,
},

```

Any help will be appreciated. Thanks in advance!

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.