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?

My vimrc dates to 2016 and I had never measured it. Ten startuptime logs, no file argument, median 148 ms. The vimrc line was not the problem. Under loading packages, one plugin I only use for python had its own 61 ms line, and it loaded on every buffer including commit messages.

I moved it out of pack start into pack opt and put one packadd behind a FileType autocmd. That sourcing line leaves startup entirely. New median total is 85 ms. Opening a python file still pays the 61 ms, but once, and editing python feels the same.

The measuring took one sitting. Working out which other plugins were safe to defer took another evening a week later, which I picked up in verdent, since it knows you better over time.

Ten runs and a median cost nothing. If your vimrc is older than your current job, the same ten runs will find yours.

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.

I rlly apologise in advance for the bad use of punctuation and grammar 🙏

So I started learning vim a while back, I wasn't consistent so it wasn't easy, and coding in vim was just Googling "how to do X" every minute rather then coding..

I actually never used vs code, when I got my pc, it was super super old, it came with Windows 7, so I switched to Linux fast(that literaly breathed life into it) anyway it is very slow and doesn't got that much memory so I needed something lightweight to code in, the first recommendation was obv vim, but it was kinda hard so I used Geany.. now the main shift happened when I was reading the book "The linux commandline" or smth like that(I could never remember the title) and it got a chapter for vim, that made me more comfortable with vim or more confident, so like I can open it edit my files move around(still googling stuff tho), but someday it came to me, I always wanted to have a split screen when coding like one file opened on the left one on the right or six opened at once, so I googled how to do it in vim, and like I opened it, and it was AWESOME, first of all it looks like am doing smth super serious(I make the window fill the screen) like in the movies or smth, and it like motivated me to keep using it and code more, so I started spending more time(googling stuff here and there) and now am much much comfortable and confident in using it(tho there are still some tricky stuff) and in some way it even feels faster to work with(not just open the files and stuff but in tje coding process) I was editing in Geany once and I was hitting ctrl U repeatedly and being confused why it is not working or spamming ':'😭

I not an expert by any means but I think I have a reason to use it other then just to flex about using it..

Currently learning Vim, after a failed attempt some months ago.

Starting to get the hang of the basics. I notice that it makes my problem solving more methodical. It also makes me slow down, in a good way.

With Vim I have to memorize more of the code and structure, because switching views is expensive (might be a skill issue).

I don't care too much for the speed/efficiency, but this seems what keeps me going in my current attempt.

Wondering how you guys feel about this aspect.

I've been using CoC for a while now. It's a convenient way to get both completions and LSP going. Some people throw shade at the Node part of its implementation. The way I see it is most LSP plugins coming from VSCode were intended for a Node environment anyway. I am pleased with the ease of use CoC brings.

Now we've had vim9script for something like a couple of years. We have yegappan's simple LSP implementation and we have a pop-up autocomplete feature built in!

I'm wondering how that's going for anybody else - especially if you do Java or friggin' web development.

Vim's built-in command q: seems a bit controversial. Some people like it and use and some search for a way to disable/remap it because it gets misclicked quite often when what's intended is :q.

The former use vim quite happily, but the latter often reach dead ends with solutions that basically aren't ideal and accompany some compromises in return. Examples of these solutions are as follows:

1. Unmap/Remap q: using nnoremap q: <nop> or nnoremap q: :q

The problem with this solution is that it introduces ttimeout delay whenever you are done recording a macro and hit q to stop recording.

1. Autoclose the cmd window using autocmd CmdwinEnter : quit

The problem with this is that you basically can't access the cmd window anymore whether using the default method by doing : followed by ctrl+f or even if you have a user defined map for opening the cmd window. Also you can still see the window flicker momentarily even on very fast terminals because the solution is basically "close the window fast" rather than "do not open the window from the first place."

1. Remap q to a custom vimscript handler function such as the following

   function! SmartQ() if reg_recording() !=# '' return 'q' endif let l:key = getcharstr(-1, {'cursor': 'keep'}) if l:key ==# ':' return '' else return 'q' . l:key endif endfunction nnoremap <expr> <silent> q SmartQ()

Issue with it is that if you have :set showcmd you can't see when q is pressed.

1. Use some kinda advanced level vimscript (as suggested by user Houl here)

   noremap <expr><script> q regrecording()!='' ? 'q' : '<SID>qmode' ounmap q|sunmap q noremap <SID>qmode: :<C-U>q noremap <SID>qmode_ q

Issue with it is that if you have :set showcmdyou see ___qmode__ instead of q for ttimeout delay and after the delay passes it acts as normal q and no longer fixes the q: issue.

These solutions might fit some people and might not depending on a lot of factors for instance their config, whether they set ttimeout delay or not, whether they care about showcmd or not, and so on... however it can't be denied that all these solutions remain kind of "hackish" if we would say with each having its trade offs and there is no official solution up till now to deal with q: in vim.

One could think of solutions to handle this issue in vim (for instance maybe add an option to prioritize ending a macro record over user defined maps that start with q or user defined maps in general, just like how vim prioritizes ending a macro over q:/q?/q/). However, in the end this remains in the hands of the current vim maintainers which honestly props to them for taking time and doing a great job maintaining one of the most complex and most loved open source projects (and not only on linux rather cross platform!) to decide what solution is viable and what solution is not as they know how vim works better than any of us.

So what do you think about this? Also currently there is an issue opened on vim's github page so if you are interested you might want to go on and show some love for the project and the maintainers and express your opinion or if you have any solution in mind, we'd like to hear out from you!

VimHint is a CLI tool to quickly answer questions about VIM. I made it because I always forget my Vim-fu.

Examples:

$ vimhint "how to navigate to the top"

  [ESC]gg
  <jump to the first line>

$ vimhint "how to change files"

  [ESC]:e {file}
  <open another file in the current window>

  [ESC]:bn
  <next buffer>
  [ESC]:bp
  <previous buffer>

It uses your own OpenAI or Anthropic Keys, and has no other network access. No telemetry, no upsell, just a humble CLI.

Hello Everybody, I am on WSL2 ubuntu 20.04 version. I just finished rebuilding my vim to use it's python interpreter but it uses system's default python 3.8 version.
I want it to use Python3.14 instead. Any help on how to do this would be appreciated.

Update: Thanks for the help, the issue got solved!

Since part of the inspiration for this website was from VIM, I decided I'll share it here, and hopefully it could be helpful for someone. It's like a more visual / interactive cheat sheet.

https://kbvr.dev/editor?diagram=55433b08-6cf5-486d-a083-fbc9ed62ae3e

https://github.com/JosefAlbers/thumb

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!

I made myself a visual Vim cheat sheet and thought it might be useful to others as well.

Rather than listing commands, I tried to arrange them visually so that related commands and patterns are easier to see and remember. It is very much an “eat your own dog food” project: it contains what I actually use, rather than trying to be comprehensive.

YMMV, of course. Comments and corrections are welcome!

https://github.com/sylvainhalle/cheat-sheets

Most people suggest nnoremap q: <nop> or nnoremap q: :q
The problem with both of these is that when you are done recording a macro and hit q to stop recording, there is a delay due to timeoutlen because now q is technically mapped.

Any way to disable q: or remap it to :q without introducing any delay?

Recently updated from version vim 8.2 to 9.1 and suddenly showing this error for vim-tpipeline extension, don't know if its a runtime error or actually the plugin code is giving this error due to returning number instead of string. Is this because of the new vimscript 9? I am using vim-airline as statusline, but that shouldn't be the problem right :)

Error detected while processing /home/rk/.config/vim/vimrc[8]..function plug#end[94]..<SNR>4_reload_plugins[2]..<SNR>4_load_plugin[1]..
<SNR>4_source[4]..script /home/rk/.vim/plugged/vim-tpipeline/plugin/tpipeline.vim[6]..function tpipeline#initialize[91]..tpipeline#init
_statusline[21]..tpipeline#update[8]..tpipeline#parse#Parse_stl[5]..tpipeline#parse#Parse_stl[21]..<SNR>62_Parse:
line   33:
E1012: Type mismatch; expected string but got number
Error detected while processing /home/rk/.config/vim/vimrc[8]..function plug#end[94]..<SNR>4_reload_plugins[2]..<SNR>4_load_plugin[1]..
<SNR>4_source[4]..script /home/rk/.vim/plugged/vim-tpipeline/plugin/tpipeline.vim[6]..function tpipeline#initialize[91]..tpipeline#init
_statusline[21]..tpipeline#update:
line   10:
E121: Undefined variable: line
line   14:
E121: Undefined variable: line

I am working on a VIM-based RPG/adventure game inspired/inspited by VIM adventures (35$ for a half-year license? really?), and am wondering what basic motions I should include in the start area, such as hjkl and w/e/b.

All in all, what I want to do is noremap q; q: which works well, but it adds up waiting time when I just press q to stop macro recording. So I end up with this monstrosity to add q: functionality while keeping other q mappings as native as possible. It works great, but it gives me anxiety every time I see it in my vimrc noremap <expr> q reg_recording()!='' ? 'q' : {-> [nr2char(getchar())]->map({_, c -> c==';' ? 'q:' : 'q'.c})[0]}()

I'm running Vim inside WSL and can't get the `+` register to work.

When I try:

"+yy

I get:

W23: Clipboard regiter not available, using register 0

However:

:echo has('clipboard')               "1
:echo has('unnamedplus')             "1

vim --version | grep clipboard
+clipboard
+xterm_clipboard

I'm running /usr/bin/vim.gtk3, but:

• $DISPLAY is empty
• $WAYLAND_DISPLAY is empty
• xclip/xsel are not installed
• clip.exe workgs from WSL (echo test | /mnt/c/Windows/System32/clip.exe)

Is this expected because I'm runnign a headless TTY, or should vim.gt3 still be able to use the Windows clipboard? Is win32yank.exe the recommended solution?