Living in the Terminal: Building a Personalized Neovim + Arch Workflow (on the Road to Gentoo)

Introduction

For the past year, I’ve been shaping my workflow around a simple philosophy: default-first, intentional choices, and learning through necessity.

I live on Arch Linux, running Wayland with Hyprland, bootstrapped through JaKooLit’s preset configuration. Arch gives me freedom to explore, but with a sensible base to work from. My editor of choice is Neovim — extended just enough to support language tooling, but kept as close to the defaults as possible so I can drop into a “vanilla” Vim or Neovim environment without struggling.

This isn’t the end goal. I want to move to Gentoo, and eventually Linux From Scratch, to strip away even more guard rails. But Arch has been the perfect launchpad for building a workflow that is both practical for daily engineering and challenging enough to force me to learn.

Why Defaults Matter

I used to pile on plugins and custom configs. Autocomplete dropping ghost text. AI tools that would refactor code for me. Dozens of Lua tweaks to make Neovim “perfect.”

But I realized something: the more layers of customization I stacked, the more fragile my workflow became. Dropping into a remote server with only Vim installed suddenly felt alien. Switching machines meant hours of dotfile syncing.

So now, I prioritize defaults. My dotfiles are lean, my AI plugins are commented out, and even completion is manual — no dropdowns unless I explicitly press <C-n>. If I don’t remember the syntax, I want to feel that friction and learn it properly.

It’s not about rejecting customization entirely. It’s about resisting the temptation to overfit my environment until I’m dependent on it.

Arch + Hyprland + JaKooLit

My current system is:

Arch Linux: a rolling, lightweight distro that forces me to stay sharp but doesn’t punish experimentation.
Hyprland on Wayland: tiling compositors feel like home now. JaKooLit’s preset gave me a working environment out of the box, and I’ve been peeling back layers to understand what each piece does.
Terminal-first workflow: most of my time is spent in Neovim and tmux. The desktop environment is just a canvas for launching and managing those core tools.

This stack feels like a sweet spot between usability and challenge. I can focus on learning without spending weeks debugging kernel compile failures — at least, not yet.

Neovim as the Anchor

Neovim is my daily driver for development, writing, and tinkering. But unlike many “rice-heavy” setups, I keep it close to stock:

Minimal plugins for syntax, navigation, and formatting.
No AI directly in my editor — I separate “thinking” from “doing.”
Intentional autocomplete: nothing happens unless I trigger it myself.

This forces me to write code with the same mindset I’d have in vanilla Vim on a production server: deliberate, syntax-driven, and not reliant on tooling to fill in gaps.

It also changes how I learn. Instead of remembering that “the plugin will handle it,” I remember the syntax, the compiler errors, and the language itself.

Tmux in Support

Tmux isn’t the star, but it’s become the glue.

My typical setup:

Left pane: Neovim, coding directly.
Right pane: OpenCode or another planning tool, where I sketch architecture and test ideas.
Other sessions: logs, REPLs, or build processes running in the background.

This lets me separate thinking and doing. The AI isn’t baked into my editor, where it might tempt me to “autocomplete my way” through problems. Instead, it lives in its own pane — a brainstorming partner, not a co-pilot.

Friction-First Design (`friction.md`)

One of the best habits I’ve built is keeping a friction.md file in my config. Every time I notice some subtle annoyance — an awkward key combo, a workflow break, an unnecessary step — I log it.

Then I ask myself:

Is this worth a new keymap?
Is this worth a plugin?
Or is this friction actually teaching me something, and I should leave it alone?

This practice has made my environment feel personal. Instead of copying configs from Reddit or GitHub, I refine my setup based on how I actually use Neovim and tmux. Every change is earned.

Gentoo Aspirations

Gentoo sits on the horizon.

I’m hesitant because of the compile times — everyone warns how long it takes. But what excites me is the DIY nature:

USE flags mean I choose what goes into my system.
Portage builds from source, so I’ll learn not just what I’m running but how it was built.
Kernel compilation will no longer be optional — it’ll be the workflow.

I know Gentoo will slow me down at times, but that’s part of the appeal. My learning style thrives on “no other option” scenarios. When the system won’t boot until I understand why, I will learn why.

And beyond Gentoo? Linux From Scratch isn’t a practical daily driver, but it scratches the ultimate itch: building a distro with no guard rails, just raw learning.

Lessons Learned

Friction is a teacher. When autocomplete doesn’t fill in the function, I have to remember it. When tmux defaults feel clunky, I have to learn them. That discomfort makes me sharper.
Default-first setups scale. I can SSH into a server and feel at home with Vim and tmux, without needing my dotfiles.
Arch is a launchpad, not the destination. It’s teaching me enough to survive, while pointing me toward Gentoo and eventually LFS.

Conclusion

I’m not chasing the “perfect riced Neovim setup” or the most polished distro. I’m chasing understanding.

Arch + Neovim + tmux, kept close to defaults, give me a daily workflow that’s practical but uncompromising. Gentoo will come when I’m ready for longer compile times and deeper system control. LFS will be there when I want to take off the training wheels entirely.

This isn’t about efficiency at all costs. It’s about building a workflow that reflects how I want to learn: deliberately, intentionally, and with as few guard rails as possible.