Hello guys! Lately I've often been using vim instead of VS code. But my habits didn't disappear: As you know, in VS code when you go to the next line, while you write conditionals or functions, IDE set
x number of tabs for you. For me it's pretty cool feature and vim doesn't have it natively. What can I write in ~/.vimrc or maybe download smth to enable this feature on vim?

I avoided vim for years, from the way people talked about it, sounded like it would be too much to learn programming and at the same time learn modal editing...but I've started using it now because I a course I started on C programming insists that people completing the course use a barebones text editor, no IDE or anything IDE-like with plugins.

Decided why not, this is my chance to learn vim. I've discovered that it behaves like a regular text editor in insert mode, then if I want to practice vim motions I can go into normal mode and practice, adding 1 or 2 new keys or combos every week or two...

Am I missing something or doing it wrong? Other than remembering to change modes this doesn't seem that difficult? I don't know most of the keys or combos but that's not a pain as I don't need to use them?

I feel like people shouldn't be talking about vim like it's this super hard thing with a steep learning curve. So far it has seemed easy to learn at a pace I have control over?

I've been getting good with vim but every now and then when I want to access a certain line, I can't move the cursor into it, it just jumps over. What I usually do it move the cursor a line above it and (number)+w a few times. Any advice for this small problem I'd be grateful.

Hi,

I have a Linux VPS and I'm currently struggling with vim... As soon as I type `:help`, the help page appears. The following shortcut is located there:

"Jump to a subject: Position the cursor on a tag (e.g. bars) and hit CTRL-]"

1.) I haven't seen a keyboard shortcut yet that had a minus sign between the keys. It’s always Ctrl+C, for example. What is the minus sign supposed to indicate?

2.) "Ctrl + closing square" bracket doesn't do anything either. I can jump to the subject by clicking the mouse or by pressing Ctrl + I. This might be due to the keyboard layout, or does "]" actually refer to the letter I?

Greetings

I don't know if this is the best sub to ask this since it's not related to VIM, the text editor, but rather the VIM Motions.

I believe most programmers who like VIM, can't use it for everything because sometimes you need the power of an IDE, and pretty much every IDE out there has some kind of VIM integration, either official or via extention.

My question is, how do you grapple with VIM shortcuts conflicting with the IDE shortcuts? Do you replace all conflicting shortcuts with VIM or just some of them? If so, which? One I always set is to keep <C-c> for the VIM extention, is a bit weird having to copy using Insert, but I'm too used to exiting Insert Mode using <C-c>. It's hard trying to find a balance between them.

If there's a better sub to ask this question, please tell me so I can move my post there.

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

vimgang,

I have vim set to open nerdtree automatically on open and shift focus to whatever file im editing. My issue is my cursor highlight stays in nerdtree and doesnt follow the file focus : /

My current .vimrc invocation:

au VimEnter * NERDTree | wincmd p

Any ideas are appreciated!

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

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.

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.

There's Arabic mode in vim but it only good if your editing only Arabic text. Is there a way to edit bidirectional text? Both LTR & RTL in the same file?

Vim is fun and cool for me when I know where things are/don't have to hold a lot of repo context in my head (where files are, where to look for things, what a file I need is called, which file I need, etc.) but at work where I'm working in multiple large repos that I understand less than 1% of, it seems impractical. Like I need a GUI to even begin navigating and searching for what I need, or when I'm trying to get a lay of the land.

Is this an issue with my abilities/tools/knowledge (i.e. I could lack knowledge on a useful way to browse a file tree in vim or something) or is this an area where vim isn't really the best choice?

I've been using vim now for the same amount of time I've been using Arch Linux pretty much.

What drew me to it was after installing Arch, I started watching different Linux videos and a lot of the config files were being edited with vim. And I was watching 3 or 4 content creators and they all, for the most part, were using vim to edit those config files. One guy would switch to something different like a GUI text editor like Geany, gedit, and kate. But vim was the one they all used.

So, watching these videos and editing my config files along with them, I was pretty much using vim as well.

I've been using Doom Emacs (most of the key bindings in Doom Emacs are the same as vim key bindings) a lot lately but for quick things, especially if I'm already in a terminal, vim is what I use.

What brought you to vim and do you use other text editors as well?

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.

So far, I've made my custom color scheme thanks to color template and solarized8, but I wanted to try to do something more complicated

I'm going to try making an "animated color pack" (fancy word for saying that i'll try to make the colors in my scheme go from a first color, to a second, to a third and so on)

I don't even know if that's doable, but I think it might be possible if I try playing around with functions (especially if i try doing that by editing code from other people to understand how plugin making works)

Sorry if I write things weirdly, I'm bad at words

Also I wasn't sure whether to post this in help, discussion or tips and tricks, so sorry if i should've posted it elsewhere

Given the following two lines:

.row.mb-5.justify-content-evenly

If my cursor is at the y in justify-content-evenly, how can I delete that word, plus the period before it without losing the newline at the end?

EDIT: I didn’t say which y my cursor was at, but either would work for my use case.

EDIT 2: End result I want is for the first line to read:

.row.mb-5

They come from https://ftp.nluug.nl/pub/vim/runtime/spell/ but I can't find much information about who put them there and where they got them from. The esperanto one seems to have typos.

This might save someone a search. I upgraded VIM-8.1 to VIM-9.1 (I know, I'm slow) and ran into a minor problem with my .vimrc file.

When scrolling through colon-command history using ": CTRL-F", "loadview" would send an error message before showing the history. It would disappear fairly quickly, but it was annoying. The old .vimrc:

" Save and restore edit sessions in directory $HOME/.vim/view (created
" for you if it doesn't already exist).  We test with expand because
" running 'vim' with no arguments throws a 'no filename' error.
" See ':h views-sessions' for more info.

if has("autocmd")
  if len(expand('%')) > 0
    au BufWinLeave * mkview
    au BufWinEnter * silent loadview
  endif
endif

The fix was using "silent!" to disable the E11 error message:

if has("autocmd")
  if len(expand('%')) > 0
    au BufWinLeave * mkview
    au BufWinEnter * silent! loadview
  endif
endif

No problems so far. Hope someone finds this useful.

I'd like to preface this by saying this is NOT an argument to convince people to switch after already building muscle memory, I'm just trying to say why I believe these binds could be an option for new vim users at least. My argument is only trying to prove why these binds could be marginally better, not significantly.

Also sorry for making this really long, I just wanted to get my entire argument out there.

How this all began was I first was configuring hyprland and was deciding on what to bind my switch window focus to. I naively decided to bind left to j, up to k, down to l, and right to ;. I used these binds for a little bit, and they honestly work perfectly for hyprland, and so I thought I would just do the same for vim. As I was using vim with these binds, I did a little research and found a compelling case to use hjkl instead of jkl;, the reason being having up and down on stronger keys then left and right is better for experienced vim usage, as there are usually other better hotkeys to use such as f, t, w, e, and all the rest.

One detail I omitted was I had been using hjkl with the traditional bindings for a while before switching to the worse jkl;, and when I was using them I found them wildly un-intuitive. My main annoyance wasn't that the keys were seemingly shifted to the side, it was that j was the down key, and k was up. I've researched a little bit, and I found that the reason it was originally made that way was the creator of vim had a specific keyboard back in the 80's or something that made it better for him to do it that way.

My question is, why can't we ditch these old binds and instead use j as up, and k as down? And let me tell you exactly why we should.

I will bring up two arguments to account for both views that I think people have to deter them from using these binds.

The first argument I will attempt to disprove is that the down action is apparently more valuable, therefore it should be on a better and easier to access key then up.

Firstly, I'd like to say that I don't even agree with this point, but I will argue from the perspective of agreeing with it. (see below for me attempting to disprove that the down action is more valuable)

There's one key factor that makes this point actually support my jk binds, and it's that the middle finger is just.. stronger then the pointer finger. That's it. Can't really say much to that, so if you were to put the stronger key on supposedly the "more valuable action," that must mean they're good binds, right?

The second argument I have as to why rebinding j to up and k to down is good is: the down action isn't even more valuable than the up action.

I'm bringing this up because even if you disagree with my last point that you disagree somehow with the middle finger being stronger then the index finger, then you can see that the down action isn't even more valuable than the up action.

To try to disprove this claim, I'll first provide why people believe it to be true. The argument that I have seen is that in vim you're usually starting from the top of a file, and typing while working down. This is absolutely true, but why would this be a plus? I'll explain in a second, but I don't know maybe I'm missing something because I genuinely don't understand how this is a plus.

The reason why I think this isn't that good of an argument is, well, the enter key.

Really one of the only times you're actually going to be going down with the key in normal mode is when you need to go down either from text that was already there, which is already deviating from the point of you being in an empty file and working down.

And the other time is when you would be going down in normal mode is well when you've just gone up. Huh, the only time in the actual scenario when you'd be going down, is, correct me if I'm wrong, when you've gone up. That would actually suggest the conclusion that down really isn't actually "more valuable" as people say, and rather how valuable it is, is tied with the up action.

I have a recurring daily scheduled ChatGPT task that teaches me a Vim tip. It knows my `.vimrc` so it tries to teach me things that are either missing or might complement or extend it. Some stuff I already know, naturally, and it has erred on the side of quite basic at times (like today), but overall it’s a nice bit of trivia with my morning coffee. I’d recommend it!

EDIT: not sure why I’m getting downvoted — this isn’t me trying to share this Vim tip; it’s me sharing the idea of having ChatGPT send one little tip per day as a nice bit of morning trivia. I guess folk aren’t reading the post body?

There used to be cool windows utility that let you with a control key copy text from any current windows app (e.g., some programming ide or word), then paste it into a vim session. You could then edit the text in vim, and then when done it copied the text back.

Does anyone recall this app?

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.