Git and Vim are both powerful productivity tools for developers. However, when working inside Vim, frequently switching to the terminal to run Git commands (such as git status, git add -p, git commit) can interrupt your flow and break your focus.

With LeaderF’s built-in Git integration, you can bring the entire Git workflow directly into Vim and significantly improve your efficiency.

This article focuses on one core command:

:Leaderf git status

Viewing Current Git Status

Run the command above in Vim to open the following view:

The screen is divided into two main panels:

Navigation Panel (Left)

The left side is the Navigation Panel, which displays the output of git status in a tree structure, grouped by file state:

• Staged Changes: Files already staged (ready to commit)
• Unstaged Changes: Modified files not yet staged
• Untracked Files: Files not tracked by Git

Diff View Panel (Right)

The right side is the Diff View Panel, which shows detailed changes of the selected file. It supports two modes:

• Unified Diff View

Provides character-wise diff highlighting, making differences more precise and visually clear. Traditional git diff does not highlight character-wise changes.

• Side-by-Side Diff View

Advantage: More intuitive for comparing code differences line by line.

How They Work Together

• The left panel handles file selection and state management
• The right panel handles diff visualization and fine-grained operations

Together, they form a smooth and efficient Git workflow inside Vim.

File-Level Operations

In the Navigation Panel, you can perform the following operations:

Notes:

• s, d, D also work on directories (including the repository root)
• Running d or D on Untracked Files will delete the file
• Press F1 in the panel to view more shortcuts

Hunk-Level Operations

In the Diff View, you can operate on individual hunks (code blocks):

Additional Shortcuts

Key Mapping Configuration

let g:Lf_GitKeyMap = {
            \ 'previous_change': '[c',
            \ 'next_change': ']c',
            \ 'edit_file': '<CR>',
            \ 'open_navigation': '<',
            \ 'stage_unstage_hunk': 's',
            \ 'stage_unstage_all_hunk': 'S',
            \ 'discard_hunk': 'd',
            \ 'discard_hunk_no_prompt': 'D',
            \ }

Committing Changes

Once you have staged the desired changes in the Navigation Panel:

1. Press c to start committing
2. A new window opens for writing the commit message
3. Enter your message
4. Save and close the window
5. The commit is completed

To cancel the commit, simply clear the message and close the window.

Example Workflow

Scenario: Fix a bug and add a new feature

1. Check status
2. Review changes
   • Open bug_fix.py
   • Use ]c to navigate hunks
   • Identify bug fix vs debug code
3. Stage selectively
   • Press s on bug fix hunks
   • Leave debug code unstaged
4. Handle new feature
   • Press < to return
   • Open new_feature.py
   • Press S to stage all hunks
5. Commit
   • Press c
   • Enter message:
   • "Fix login validation bug and add search feature"
   • Save and exit

Everything is done inside Vim without breaking context.

Why This Workflow is Better

Compared to CLI

Summary

With Leaderf git status, you get a complete Git workflow inside Vim:

• Visual Git status
• File-level staging/unstaging
• Hunk-level fine control
• Quick discard
• Seamless commit workflow

All without leaving Vim.

Configuration Example

nnoremap <leader>gs :<C-U>Leaderf git status<CR>

Vim's built-in Python syntax doesn't treat annotations differently from other code. In def get(key: str) -> User | None, str gets the same color as a str(x) call, and ->, User and | aren't highlighted at all. I write a lot of typed Python and wanted the types to stand out, so I made a replacement syntax/python.vim that colors types only where they're actually types:

• parameter and return annotations, x: T and self.attr: T, class bases, and PEP 695 def f[T] / type X = ...
• list(...) in code stays a builtin, | outside a type is still bitwise or, and key: value in a multi-line dict isn't treated as an annotation
• # type: comments, docstrings after wrapped signatures, match/case, except*

By default every group links to a standard one (Type, Operator, ...), so your colorscheme picks the colors; the screenshots use retrobox. The second image shows the optional palette (let g:python_enhanced_colors = 1).

Install with Plug 'aaronbcarlisle/python-syntax-enhanced', any other plugin manager, or pack/*/start. It replaces the built-in syntax file (it started from Vim's own python.vim, credited in AUTHORS), so you'll need to disable other Python syntax plugins.

Limitations: types are found by position, not analysis, so any name inside an annotation gets the type color. It's also slower: highlighting a whole file from scratch takes about twice as long as the built-in syntax (measured on an 11k-line file). While you edit, Vim only highlights what's on screen, so I haven't noticed it in practice, but it's next on my list. That said, if you have an 11k-line Python file, I probably have more questions for you than you have for me :p

On AI: I built this with a lot of help from Claude Code and Cursor, which you'll see in the commit history. I'm one of only a handful of Vim users at work, and when we moved to Python 3 and made type hints part of our coding standard, I couldn't find a Python syntax plugin that handled them. I didn't have the time to write it all by hand, so I worked back and forth "with the agents that be". I spent my own time on making sure it wasn't just a solution for my own setup: the highlighting is covered by 86 assertions that check the highlight group at specific positions, and CI runs them on Linux, macOS and Windows. We're on Python 3.11 at work (the VFX Reference Platform just moved to 3.13, I believe), so that's what it's seen the most real use on, but the 3.12 syntax is covered by the tests too.

The biggest headache with using AI was all the regressions along the way: fixes that weren't ideal and had side effects on how other things highlighted. A lot of the work on my end was testing scenarios that hadn't been considered, like taking a long list on a single line and splitting it across multiple lines, just to watch every item except the first one and the closing bracket change to a different color, or the whole file turning yellow when scrolling >.>

Overall, it was a nice quality-of-life win: AI did the building, so nobody asked why I wasn't staying on task (or worse, shamed me for not using an IDE). Hopefully others will find it useful too.

https://github.com/aaronbcarlisle/python-syntax-enhanced. Bug reports with a code snippet are most welcome.

Works with the latest vim master branch (or latest windows build from https://github.com/vim/vim-win32-installer/).

Looks pretty good so far combined with https://github.com/h-east/lsp.vim

Comentador

A Vim9script plugin for toggling both inline and block comments with full operator-pending support. While inspired by tpope's Commentary plugin, Comentador has its own unique behavior and features. Key differences being everything is a toggle, single blank line auto-insert, and not being able to comment an already commented line. There are even more differences of course!

Requirements

• Vim 9.0 or higher.

Documentation

Use the :help Comentador command for a complete documentation of usage and behavior.

Default Mappings

Use gcc to uncomment any comment type.

Use gbb when you specifically want to comment or uncomment block style comments.

Text Object Commands

The gc and gb mappings work as text objects with other operators:

Blank lines adjacent to comment blocks are included in the selection. With d or y, leading blank lines are trimmed but trailing blank lines are preserved. With c, blank lines are trimmed from both ends.

Command-line Commands

Without a range, commands operate on the current line.

Plug Mappings

Override default mappings using <Plug> mappings:

Example:

nnoremap <leader>c  <Plug>(Comentador)
nnoremap <leader>cc <Plug>(ComentadorLine)
xnoremap <leader>c  <Plug>(Comentador)
onoremap <leader>c  <Plug>(Comentador)

Comment Markers

Markers are automatically parsed from 'commentstring' and 'comments' options and cached in b:comentador_markers. For unsupported filetypes, set 'commentstring' for inline comments. If block markers are missing (no s1 and ex flags in 'comments'), add them to the existing value:

autocmd FileType apache setlocal commentstring=#\ %s
autocmd FileType myfile setlocal comments+=s1:/*,ex:*/

If no comment format is defined for a filetype, all mappings will display "No comment format defined for this filetype".

I have lost track of how many note taking plugins exist for Vim. I nevertheless decided to make my own in vim9script. Initially it was part of my configuration but then when I learnt that image support was added natively to Vim, I decided to make it into a proper plugin and decided to share it here.

Features:

- Note linking

- Image rendering

- Calendar view of daily notes

It has some limitations, most notably that it only works on Linux systems because I use shell commands a lot. (The calendar UI is made using the cal command, the images are actually generated by a user definable shell command which is then piped to ImageMagick for resizing and conversion to RGBA). It has some other quirks but I think it works well for me.

Anyways enough ranting here is the plugin: https://codeberg.org/zoomlogo/pen.vim

I've released version 0.1.0 of vimls-go, an open-source language server I'm building for legacy Vim script and Vim9 script. I'd love feedback from people writing Vim configurations and plugins.

Source and setup instructions: https://github.com/neoclide/vimls-go

Prebuilt binaries: https://github.com/neoclide/vimls-go/releases/tag/v0.1.0

It provides completion, hover documentation, signature help, go-to-definition, references, diagnostics, semantic highlighting, and rename support. Cross-file analysis includes Vim9 imports and autoload functions. Formatting currently focuses on indentation.

One feature I particularly wanted is help from installed plugins: the server indexes Vim files on runtimepath and extracts documentation from doc/*.txt. Hover can show help for plugin variables, functions, and commands, with the source file path and line number. Changes to runtimepath are handled incrementally.

The server is a standalone Go binary. In Vim, you can use it with an LSP client such as coc.nvim or vim-lsp; the README has configuration examples. Download the binary for your platform, rename it to vimls (vimls.exe on Windows), put it on PATH, and configure your client to run it for Vim files.

This is the first release, and static analysis has limits around execute and dynamically generated names. I would especially appreciate small reproductions of incorrect diagnostics, missing completions, or trouble with real-world Vim9 code. Please feel free to open an issue or share feedback here.

TLDR; I forked and fixed a few bugs from the original iamcco/markdown-preview.

markdown-preview.nvim is a vim & nvim plugin that lets you preview markdown files in the browser and automatically reloads when you make changes.

What’s different

• No Node.js. The server is a single binary: no npm install, no yarn, nothing in the plugin directory to build. Pre-built for macOS (x64/arm64), Linux (x64/arm64), Windows x64 and FreeBSD x64.
• Vim fixes: g:mkdp_auto_close works in Vim now (it used to miss that Vim unloads the buffer on leave), and the commands exist in the first buffer even when the plugin is loaded on filetype.
• WSL works: the browser opens with wslview, cmd.exe or xdg-open, whichever you have.
• g:mkdp_browser takes a list, run as a command with the URL appended: let g:mkdp_browser = ['firefox', '-P', 'work'].
• Links between markdown files work: clicking [guide](docs/guide.md) in the preview opens that file, and the URL is the file’s path, e.g. /files/docs/guide.md.
• Security: other web sites can no longer read your buffer through the local WebSocket, and g:mkdp_open_to_the_world now needs a token in the URL.
• New in the page: GitHub alerts (> [!NOTE]), a front matter panel, a full-screen Mermaid viewer (zoom, pan, save as SVG), diagrams that follow the dark theme, and themes from shadcn via g:mkdp_theme_css.

Everything else works as before: live updates, synced scrolling, KaTeX, Mermaid, PlantUML, Graphviz, Chart.js, footnotes, table of contents, local images, custom CSS. Your existing g:mkdp_* settings keep working.

Plug 'sammaji/markdown-preview.nvim', { 'do': { -> mkdp#util#install_sync() }, 'for': ['markdown', 'vim-plug'] }

Repo: https://github.com/sammaji/markdown-preview.nvim
Docs: https://mkdp.sammaji.com

Full credit to u/iamcco for the original.

Yo Vim folks 👋

Vim just shipped click handlers *and* a scrollbar for the tabpanel (9.2.0386) ✨

The tabpanel isn't just a boring label strip anymore. It's a real little UI playground now 🎨 You can click stuff, scroll stuff, and basically host tiny "apps" right inside Vim 🪟

Things that were painful before and are actually fun now:

- 🖱️ Mouse clicks on whatever you render in the tabpanel

- 📜 Long content scrolls instead of getting chopped

- 🧩 Plugin UIs that feel like proper side panes — no extra window juggling

So… file trees 🌲, chat panels 💬, RSS readers 📰, dashboards 📊, weird experimental toys 🧪 — all fair game.

Have fan.

This is quite a small function, but it's made a big difference for me, especially when pointing to something outside my project.

Yank file location references to the system clipboard, ready to paste into an AI agent prompt.

When working with an AI coding agent, you often need to tell it where to look. This plugin lets you grab a precise file reference.

Try it with "Focus on <paste>" or "see <paste>" in your prompt.

What gets yanked

Paths are relative to the current working directory when beneath the cwd, absolute otherwise.

The default mapping is <Leader>a in both normal and visual mode.

https://github.com/ShayHill/vim9-agent-context

"Quieter" and I think faster than pasting code and waiting for the agent to find it.

I wrote this plugin because I was constantly switching from the main buffer to the terminal where I was running pi (the coding agent) - digging through logs, sending follow-ups, checking what it did to my files.

Why keep switching, when I can just embed pi inside vim?

vim-pi-chat puts the whole pi conversation in a split window next to your code: - streamed replies, tool calls with args and results, thinking — all live - when pi edits the file you're viewing, the buffer reloads automatically (you watch it work) - it tracks your active window so pi edits the right file in place - sessions persist per file: reopen a file, :PiChat, resume where you left off - plain Vim 9, no GUI, no Neovim, no other plugins — just the job/channel API

Install: git clone https://github.com/galeone/vim-pi-chat ~/.vim/plugged/vim-pi-chat + one line in vimrc, then :PiOpen.

If you're a pi fan, give it a try — feedback very welcome :D

I never liked built in explorer, it's clunky and has annoying binds, so here is my own take on it, it uses a raw buffer to list files/directories, you use vi-motions to modify/create files/directories then apply changes to disk with :w, each file/directory has a given ID for tracking, there are bugs but it works pretty well for what it is.

It's more of a prototype than a replacement, but I'm curious what people think about it.

stqqrm/bex.vim

https://github.com/JosefAlbers/thumb

Please be gentle, first time publishing something publicly.

I use this emacs' eww-inspired html/plain text browser that uses curl and pandoc to do html -> plain text into a vim buffer. It is sufficient for my daily quick searches and keeps the results in a vim buffer for reference.

If this is useful and works for you, I would appreciate feedback on publishing and maintaining this as a plugin for everyone

I wrote a plugin to help with automatic table creation, it offers a lot of customization and supports box drawing characters. One particularly neat thing about it is the cell editor that opens the cell into a new buffer. Hooks are provided so any vim or external tool can be used for formatting or anything else.

Feedback is appreciated!

https://github.com/numEricL/table.vim

Hi r/vim!

I wanted to share a plugin I've been refining called Vispen. It brings the power of Polyglot Literate Programming right into your editor, but without the massive overhead, background daemons, or heavy dependencies of modern alternatives.

👉 GitHub Repository & Live Demo: github/vispen

💡 What is it?

If you love the concept of Jupyter Notebooks or Emacs Org-mode but hate the .ipynb JSON bloat, active server sockets, and constant context switching, Vispen is for you. It allows you to execute embedded snippets of SQL, data transformations, and templates directly from your source files or markdown documents, embedding the results straight back into the buffer.

🚀 Key Features:

• Zero-Socket Architecture: No background servers, node processes, or active ports. It uses Vim's native interface to run seamlessly.
• Smart Context Awareness: Execute a query under your cursor, format text, parse CSV/JSON, or dump structured database outputs into clean text tables, HTML, or ready-to-paste Jira markup.
• Lightweight & Fast: Inherits architecture ideas from heavyweights like YCM but stripped down to be blazing fast and minimal.
• Vim-Friendly Customization: Zero forced global keybindings. It uses proper <Plug> interfaces so it won't mess with your carefully crafted .vimrc.

🛠 Requirements

It works out of the box on lightweight systems (runs perfectly even on my Orange Pi single-board computer!):

• Vim 8.0+ compiled with +perl support.
• Perl 5.006+

I built this to scratch my own itch for a fast, predictable, and clean terminal workflow. I’d love to hear your feedback, feature requests, or thoughts on the architecture!

curl is an amazing tool to do REST API tests, which I do quite often using vim to generate actual curl commands. There are multiple ways to do it using vim, the one I have is

https://github.com/habamax/vim-curl

--url https://openlibrary.org/api/books?bibkeys=ISBN:0201558025,LCCN:93005405&format=json

--url https://api.sunrise-sunset.org/json?lat=36.7201600&lng=-4.4203400

# --jq is not curl parameter. If added, curl output would be piped through jq
--url https://httpbin.org/post
--header "Content-Type: application/json"
--jq
--data
{
"string": "hello world",
"number": 69,
"date": "2024-04-09"
}

Place a cursor on a text or select it and run :Curl to invoke curl cli command with an output in a built-in vim terminal.

https://asciinema.org/a/1257605

https://github.com/Joekrry/vimline-errors

Hi all, I have built a very well known tool for native vim 9.0+ based on the style of this neovim tool https://github.com/rachartier/tiny-inline-diagnostic.nvim .

Obviously in line error checks have existed for years but I haven't been able to find a tool that has this style for native vim. Please let me know if it does exist. If not, please consider starring or contributing as I am only a student and should really be focussing on my dissertation lol

One thing that I always loved about Spyder (the notorious python IDE) is its beautiful variable explorer. I have never found a handy and well-done variable explorer like Spyder's.

Now, I finally managed to recreate something very similar in vim-replica!

ubaldot/vim-replica: The ultimate REPL!

Some history:

Vim-replica was the first plugin that I have ever written and it evolved as I learned new stuff. The motivation was due to vim-slime didn't work well on Windows and other REPL plugins didn't fit my need. But also because I wanted to learn more about Vim. So, I stared its development back in years.

During last Xmas vacation, while in the Philippines, I had some idea on how I could have made a variable explorer. And I learned few lessons the hard way, that many of you can spot as I explain next:

• For a simple variable explorer, I though to use term_sendkeys() and then capture and parse what the terminal spit out. I was thinking that at the end all I have to do is to pick and parse everything from the term_sendkeys() command until the next prompt and I should be set. How difficult can it be? But then I noticed that what a terminal emulator spit out include lot of rubbish (escape sequences, etc). I start to parse char-by-char and bloat the plugin with a plethora of regex. I created a monster! I spent huge amount of time chasing something that you should absolutely never do: try to parse raw terminal strings. Never ever!
• Sad for all the time wasted, I started to study an alternative way to make the processes Vim and the program running in the REPL to talk one each other, and I was thinking to make some magics through pipes and tee:s, a bit like it is donne with Termdebug. But no. That is not possible in this case.
• At the end the easiest was to simply exploit sockets. Vim support it and the programs to run in the REPL (mostly Python, Julia and R) do so. That was the key to success.
• However, I learned many things during this journey, despite it costed many headaches: for example I learned base64 encoding and that jupyter-console is pretty much an abandoned project, just to cite some. In-fact, I ditched jupyter-console but now REPLica uses native programs.
• I also started to use some AI for the first time for coding, especially for the init scripts used for Julia and R that are not really my languages. The Vim part was done pretty much and the addition was not huge, so I fixed it by myself. However, for Julia the AI entered in a loop of hallucinations and the end I had to fix the issue by myself anyway, but, generally speaking, the help of an AI is undeniable.

Well, sorry for the lengthy message but I am very happy about the outcome. Enjoy!

Those working with vim -d (or vimdiff) or with :diffthis for two-way diffs, might find EasyDiff convenient.

Key Features

• Diff Merge, Delete & Undo: Uses <Left>, <Right>, <Delete>, <S-Delete>, and <Backspace>.
  • Context-aware: Regardless of whether the cursor is in the left or right window, pressing <Right> always merges from left to right.
  • Deletes: One-sided / Two-sided with <Delete> / <S-Delete>
  • Atomic Undo: <Backspace> undoes merges/deletes across windows, including two-sided deletes performed with <S-Delete>.
• Diff Navigation:
  • Within a Diff: <PageUp> (Start of Diff) / <PageDown> (End of Diff). Works in Visual mode as well (e.g., <PageUp>V<PageDown>).
  • Between Diffs: Move between Next/Previous or Jump to First/Last with <Up>, <Down>, <Home>, and <End>.
• Edge Case & Advanced Diff Handling:
  • When a cursor line represents multiple diffs (filler vs. changed/added vs. EOF filler), lets the user to choose the target diff for the operation.
  • Transparently handles both grouped and split diffs when using diffopt+=linematch:{n}.

GitHub Repository:https://github.com/gnarendran/EasyDiff

Hi all!

I have updated this plugin that I use on daily basis, given that I switched career and I am no longer a software developer - but my love for Vim never faded and it is my go-to tool <3.

The added feature is about table handling: it is now easy to create, format, modify cells and in tables.

The next features that I plan to add are the following:

1. Multi-row/multi-column tables,
2. Links sanitizer, copy/paste links,

Unfortunately, I don't have the same time I had before, but I am open to receive good PR:s. :)

Check it out and let me know what you think!

Hello Everyone,

I’ve been experimenting with integrating the Claude CLI directly into Vim and built a small plugin around a structured :Claude <subcommand> interface.

The goal is simple: run Claude from inside Vim without leaving the editor.

Github: https://github.com/rishi-opensource/vim-claude-code

What it supports

• <C-\> toggle to open/close Claude
• 22 subcommands (explain, refactor, review, test, etc.)
• Uses visual selection when available, otherwise falls back to the current function
• Multiple window layouts (splits, vertical, popup, tab)
• Auto-reloads buffers if files change on disk
• Git-aware (starts at repo root; separate sessions per repo)
• :Claude doctor health check
• Configurable via g: variables (with buffer-local overrides)

Internally it’s built around a central :Claude dispatcher and tries to stay self-contained without interfering with existing Vim setups.

I’m mainly curious about:

• Whether the :Claude <subcommand> approach feels idiomatic
• If the window/session behavior makes sense in real workflows
• Any obvious improvements before iterating further

If there’s interest, I can share the repo in the comments.

Thanks.

Hi all,

A couple of years ago I started to write a plugin based on the hype (and beauty I must say) of lazygit, and I was wondering whenever it would be possible to replicate something similar through Vim9.

Then, due to lack of time I parked the project but the architecture I had in mind was clear: use `systemlist()` to call git commands and write the returned values in some scratch buffer inside of Vim, and add some buffer local keybindings for the various git operations. Nothing esoteric.
Moreover, the ambition was small: just "code" the most common git commands that I use daily and use a sort of "lazygit" UI, though the architecture is such that any extension should be easy.

These days I have some time to spend in Vim9 coding and I finally finished this plugin, also with the help of an AI agent, which is something that I never used before, though I had to manually correct it many times - I believe that AI agents are not very good in Vim9 scripting yet!

Well, regardless, I hope you enjoy it! :)

I just published the first release of my plugin - VimExplorer.

The title of the post sort of explains what this plugin does. With it you can create, rename, delete, move, copy your files as if you are editing a vim buffer. all your vim keybindings should work.

Imagine writing a macro to edit multiple files :P

Anyways, here is the link to the repo: https://github.com/Ashik80/VimExplorer

Would love feedback! And feel free to create issues if you find any, in case you decide to use it.

Over 100 plugins now on the awesome-vim9 list. Many slept on, so have a look around.