My Hands Keep Reaching for the Mouse
I’m writing code in Zed. It’s a great editor. Fast. Beautiful. Modern. Native Wayland support. Everything works out of the box.
But every time I need to navigate to a different file, my hand leaves the keyboard and reaches for the mouse. Every time I want to jump to a function definition, I’m clicking. Every time I need to select multiple lines, I’m dragging.
My keyboard-driven, terminal-first, tiling window manager setup has one weak point: my editor.
And it’s starting to bother me.
Why Zed First
When I switched to Omarchy, I needed an editor that just worked. VS Code was familiar but felt clunky on Wayland. Heavy. Out of place in my minimal setup.
Zed was perfect for the transition. Modern GUI editor. Familiar paradigm (looks and feels like VS Code). But written in Rust, native performance, actually works properly on Wayland.
I could jump in and be productive immediately. No learning curve. No modal editing confusion. Just point, click, type. Like every editor I’ve ever used.
For three weeks, it was exactly what I needed.
But then I started noticing the pattern.
The Pattern I Couldn’t Ignore
My workflow in every other tool: pure keyboard. Hyprland window management? Keyboard. Terminal navigation? Keyboard. File management? Keyboard. Browser (mostly)? Keyboard.
My workflow in Zed: keyboard for typing, mouse for everything else.
Opening files? Mouse. Navigating between functions? Mouse. Selecting blocks of code? Mouse. Managing split panes? Mouse.
It felt… wrong. Like I was context-switching between two different paradigms dozens of times an hour.
I’d be flying through terminal commands, switching workspaces with keyboard shortcuts, tiling windows instantly - and then I’d open my editor and suddenly I’m reaching for the mouse like it’s 2010.
The friction was real.
Omarchy’s Default: LazyVim
Omarchy ships with Neovim pre-configured with LazyVim. I’d been ignoring it because, honestly, Vim terrified me.
Modal editing. Arcane commands. The learning curve everyone complains about. The running joke about not being able to exit Vim (:q! - I know that much, at least).
But LazyVim is different. It’s Neovim with a pre-configured setup that includes sane defaults, modern plugins, and a which-key menu that shows you available commands when you pause.
It’s training wheels for Vim. Which is exactly what I needed.
One evening, frustrated after reaching for my mouse for the hundredth time that day, I thought: “What if I just… tried it?”
Day One: What Have I Done
Opening Neovim for the first time was disorienting.
I tried to type. Nothing appeared. Because I was in “Normal mode” and Vim thought I was trying to issue commands, not write text.
I pressed i. Suddenly I could type. But how do I save? How do I exit? How do I do literally anything?
I pressed Escape. Back in Normal mode. I pressed Space (the leader key in LazyVim). A menu appeared showing me options.
Oh. Okay. This is helpful.
I spent an hour that first evening just trying to do basic things. Open a file. Edit it. Save it. Close it. Navigate between files.
Everything that took one second with a mouse took thirty seconds with Vim motions I had to look up.
I wanted to quit. Go back to Zed. This was stupid. Too hard. Not worth it.
But I’d committed to trying it for a week. Just to say I gave it a fair shot.
Day Three: The Muscle Memory Fight
My fingers kept trying to do mouse things. Reach for the trackpad. Click where I wanted to go.
Instead, I had to think: “I want to go to that function. That’s… 10 lines down? 10j. No wait, } to jump to next paragraph. Or /functionName to search.
So many options. None of them felt natural.
I was slower. Noticeably slower. Code that took me 30 minutes in Zed was taking 45 minutes to an hour in Neovim. Not because Neovim was slow - because I was still learning.
But something was happening. Small moments where the Vim way felt… efficient.
Deleting a word: daw (delete a word). Faster than double-clicking and pressing delete.
Changing text inside quotes: ci" (change inside quotes). Way faster than selecting with mouse.
Jumping to a specific line: 42G (go to line 42). Instant.
Individual motions were faster. I just wasn’t fast at chaining them together yet.
The Week Mark: Something Clicked
Seven days in and something shifted.
I stopped thinking “I need to delete this word, how do I do that in Vim?” and started thinking “daw” automatically.
My fingers started executing motions before my brain fully articulated what I wanted to do.
I wanted to change text inside parentheses. My fingers typed ci( before I consciously decided to.
That’s when I realized: I was learning a new language. And like any language, it feels awkward until suddenly it doesn’t.
The breakthrough moment: I was refactoring a function. Needed to rename a variable throughout the file.
Vim way: * to highlight all occurrences of the word under cursor, cgn to change the next occurrence, type the new name, then . to repeat the change on each subsequent occurrence.
It took five seconds. No mouse. No dialog boxes. Just keystrokes.
I laughed out loud. “Oh. That’s why people use this.”
Two Weeks: The Mouse Sits Idle
By week two, I wasn’t reaching for the mouse anymore. My hand would start to move, then stop. “No, I can do this with motions.”
Navigation felt natural. w to jump forward a word. b to jump back. { and } to jump between blocks. gg to go to top of file. G to go to bottom.
Editing felt powerful. dd to delete a line. yy to copy it. p to paste. u to undo. Ctrl+r to redo.
The visual mode was incredible. V to select lines. v to select characters. Ctrl+v for block selection. Then any editing command works on the selection.
I could manipulate code faster than I ever could with a mouse.
The LazyVim Advantage
Here’s what made this possible: LazyVim’s which-key integration.
Press Space (the leader key) and wait a second. A menu appears showing all available commands organized by category.
Space + f : File operations (find, recent, grep)
Space + b : Buffer operations (list, close, navigate)
Space + g : Git operations (status, diff, blame)
Space + l : LSP operations (definitions, references, diagnostics)
I didn’t have to memorize everything. The menu taught me as I went.
LazyVim also came with pre-configured LSP (Language Server Protocol) support. Autocompletion, go-to-definition, inline diagnostics - all the IDE features I was used to, but in a terminal-based editor that never needed my mouse.
What I Lost
Transitioning from Zed to Neovim wasn’t all wins.
Visual feedback: Zed has beautiful UI. Smooth animations. Visual indicators for everything. Neovim is text in a terminal. It’s minimal. Some people love that. I missed the polish.
Onboarding: Zed is intuitive. Anyone can pick it up. Neovim has a learning curve. Even with LazyVim, it takes time.
Mouse fallback: Sometimes the mouse is actually efficient. Quick one-off selections. Clicking a specific character in a long line. With Vim, I had to commit to keyboard-only.
But honestly? After three weeks, I don’t miss any of that enough to switch back because I feel already fast even though I am still very far from my potential once I fully master the vim motions.
What I Gained
Speed: Once the motions became automatic, I was faster. Noticeably faster. Code reviews, refactoring, navigation - everything got quicker.
Consistency: Every tool in my workflow now uses keyboard-first interaction. No more context switching between paradigms.
Power: Vim motions are composable. d deletes. w is a word. dw deletes a word. d3w deletes three words. diw deletes inside a word (not including spaces). The combinations are endless.
Focus: No mouse means my hands stay on the keyboard. No visual UI means fewer distractions. Just code and editing commands.
Confidence: I can edit text faster than I can think. The editor isn’t a bottleneck anymore. Mastery of vim motions is what I need to improve more.
Where I Am Now
Thirty-seven days into my Omarchy setup, and Neovim (via LazyVim) is my daily driver.
I still use Zed occasionally. When I need to show code to someone who doesn’t know Vim. When I’m doing a quick edit and don’t want to think about motions.
But 95% of my actual development? Neovim.
My hands barely leave the keyboard now. From window management to file navigation to code editing, it’s all keyboard-driven.
The terminal isn’t just where I run commands anymore. It’s where I do everything.
And the best part? Omarchy made this easy. LazyVim was already configured. All the plugins worked out of the box. LSP servers were pre-installed. I just had to learn the motions.
If I’d had to configure Neovim from scratch while also learning Vim, I’d have given up. But LazyVim gave me a functional editor immediately, and I learned as I used it.
That’s the philosophy I’ve adopted for this whole journey: use good defaults, learn the system, customize only what matters.
I learned Vim motions. Now I use them every day. That matters.
I didn’t configure every Neovim plugin from scratch. That doesn’t matter.
The editor works. I’m faster. My workflow is consistent.
Mission accomplished.
The Unexpected Benefit
Here’s what I didn’t see coming: Vim motions work everywhere.
My terminal (zsh with vi mode). My browser (Vimium extension). I am still exploring how to use vi-style keybindings to all other apps/packages I use.
Learning Vim didn’t just make me faster in my editor. It made me faster everywhere.
One learning curve. Dozens of tools that now feel natural.
That’s the compound effect of terminal-first workflows. Everything speaks the same language. Once you learn it, you’re fluent everywhere.
Three months ago, I was clicking through Windows menus. Now I navigate entirely through keyboard commands, using the same motions across every tool.
The consistency is beautiful.
I am still far from mastering the vim motions but the path is clear and I can see myself zooming through neovim and all other apps I use in the next couple of months.
The arch.log series: My journey from Windows to Arch, from GUI to terminal, from mouse to keyboard. Learning that sometimes the hard way is the way that sticks. Still shipping. Still learning. Still brutally honest about what works.