Most of the things I do with Neovim I could probably also do with VS Code (not sure about autocommands and macros though, I haven't used Code in years). I don't use a mouse much, I have a very keyboard-centric workflow. I was a Code user for years, but did most everything else in the terminal. I figured I would give it a try and I ended up just liking it. I like to tinker. I like to tweak my configuration. I like how I can set autocommands for things, pipe text into Vim and manipulate it, or record a quick macro for some repetitive task. I like that there are "Vim keymap" plugins for things like Firefox, so learning basic Vim keys has helped me outside of Vim. I like that I keep discovering new things Vim can do (and then promptly forgetting them most of the time, but still). I also like to spend 2 hours writing something to automate something that saves me two seconds.

It's absolutely not for everyone, though it looks like some of the pre-built configs (NvChad, LaZyVim, etc.) are decent enough of the box now that you don't need to go on the endless-customization journey if you don't want to. To me though, that's the appeal: tinkering, tweaking, refining. Generally when people ask if they should use Vim, I tell them probably not but try it for a few weeks and see if it clicks in your brain. I had a great VSCode setup, everything worked great, I was productive, but something about Vim just made more sense to me once I got over the hump of modes and all the keymaps you need to turn into muscle memory.

Edit: I also like that I can do abominations like:

("def" @keyword (#set! conceal "ƒ"))

("if" @keyword (#set! conceal "?"))

("unless" @keyword (#set! conceal "¿"))

("else" @keyword (#set! conceal "∶"))

("elsif" @keyword (#set! conceal "⁇"))

("case" @keyword (#set! conceal "⟨?"))

("when" @keyword (#set! conceal "→"))

("begin" @keyword (#set! conceal "⌊"))

to make Ruby look absolutely insane. Is it useful? No. Do people hate it when I share my screen? Yes.

In the end, it's still just a text editor. Don't expect that you will get things done n times faster than in vscode without extra effort added.

  > I'm a VSCode user and when I hear people talk about neovim and it customizability

I think it's more customizable than vscode, but you need to learn some lua or vimscript to customize it. Back then I tried to create some custom keybindings in vscode and realized you can't add new ones, only modify what exists. While (n)vim provides you with out-of-the-box flexibility and more if you use something like LazyVim.

  > Is it because it's faster?

What I retroactively like about (n)vim is that, after the initial learning cost, it turns out the default nvim keybindings are transferable to many UNIX tools (less/more, man, journalctl, etc). It feels much more comfortable to write some code in nvim, open up a terminal, and then `man X` without mentally switching the keybindings.

  > Maybe it's because it's an editor you can easily use while ssh'd into a remote machine?

Actually, rather than nvim itself, it's more like vim is already preinstalled in many popular server distros. It's sometimes a huge time saver in cases where you're unable to install additional packages to edit some config/code/text files, just type `vim`/`vi` and you're good to go.

I did convert myself from a minimal vscode setup (disabled everything & only LSP extensions) to LazyVim nvim a few months ago. I had to tweak my .config/nvim, relearn Lua again, and read the manual. It took me about a week to settle things down and get used to basic nvim bindings.

After another week of suffering trying to fix JDTLS (Java LSP) integration, I'm enjoying my nvim setup. Unlike vscode sync which requires you to login, I could just git clone my `.config/nvim` and I'm good to go.

When using vscode or its derivatives, I find the customizability is very limited. You have a couple of settings, but any new functionality basically requires writing a whole new extension and nobody really does that.

Meanwhile with vim I often add one or two lines to a local vimrc script which adds some project-specific command or keybind. For example - take ioctl name under the cursor, translate to the handler function name and open corresponding driver file in split view. It only saves a couple seconds but makes it so much more natural to analyze code. I have no clue how I would go about doing that in vscode.

If you dislike the terminal or aren’t comfortable there, you should try using the vim keybinds for VSCode. They’ll get you most of the way there, and the rest is a lot of customization to get things how you like. The vim motions are the best part! They take a while to get used to, but they’re incredibly convenient.

I don't want to sound like "advising", because long-term recommendations often carry the personal weight with them- whatever I tell you worked (or didn't) for me had an effect on me - it's never guaranteed to have any implications on someone else's life.

But here's what I learned after a long time trying different things and what's worked.

Don't try to find objective reasons for making big shifts in your workflow - be that a change of your major tool, language, technique, or paradigm. What I mean is: don't try to decide if any concrete tool would be good for you. Instead, try to understand the big underlying idea behind the tool. Once you comprehend the abstraction, choosing a concrete implementation of that idea wouldn't really matter - you can carry the big idea with you regardless of one concrete implementation.

In practice, here's what I mean: the idea of vim-navigation is absolutely beautiful, pragmatic, and fantastic, and it's positively worth every minute of the initial learning curve. It's really not that hard - it only requires just a bit of dedication and discipline. I honestly don't understand programmers who choose to be in this field, yet outright reject the mere idea of it after trying it for like six minutes.

Just go with it - you probably will hate me, everyone else in this thread, and yourself for a few days, but then it will grok. Once you have a good understanding of its tenets, you could easily take it to whichever medium you choose to stay in and it doesn't even have to be neovim.

Neovim might be great for you, and maybe not even as a concrete tool to achieve defined goals, but even as a head-start medium to understand the 'big idea' of vim-navigation.

Finally, whenever picking up a new thing, maybe don't try to find elevator pitches. After the initial acquaintance - Wikipedia, GitHub pages, etc. - google instead: "Why does [that thing] suck..." and maybe try instead to find compelling reasons to remain skeptical. Trying to remain unconvinced may help you find perspectives for why a certain idea is a matter of fact might be a good one to have in your pocket.

I used vim for decades and the sensation is that I can hold the code in my hands and manipulate it directly. Other editors feel like I’m wearing thick gloves, can’t move correctly.

but it’s like learning to play the piano, it only feels natural after years of practice

nowadays I’m faster with Cursor so it doesn’t matter as much

Used to use VSCode. There was a point in time where it felt clunky on Wayland due to electron.

Neovim worked the same just about everywhere and I could choose my terminal. Especially with tiling, for me it's just feels better.

If you like using VSCode and are productive in it, keep on using it.

The big advantage of vim/neovim is that you can do everything in the keyboard and it can be very efficient. It is also lightweight.

However the learning curve is massive IME. I don't like either and pay for Jetbrains tooling.

For one, you don't have to figure out how to remove whatever random AI UI element and integration MS decided to introduce and turn on by default every update.

> is it doesn't really get across to me why the author likes tinkering so much or why I should either

It's literally stated in the second paragraph: "It’s how I learn." You can learn how the things around you work by tinkering with them.

Of course, you can then ask why someone would want to learn things, or why they enjoy learning, and I honestly don't know how to explain that, but I feel like it's the sort of thing that shouldn't need to be asked.

The fact that the author went out his way and styled it very uniquely displays that he does have taste :) It is just that your taste is different. Like another commenter pointed out, I liked the style (though I hated the pixelated font to begin with)

Funny part is he points out at the end that it's highly subjective...

I actually really liked the look of the blog. It gave me a retro vibe, which is obviously what he was going for. But I'm also reading on my phone. Maybe the choice was more annoying on a larger screen.

Once one gets over the infatuation phase one realizes how subjective taste really is. I thihk there are some common points though that one can tell someone has refined taste without necessarily liking it

I just came here to say I think the blog design had a really cool look, it brought me back to my early days plugging away on old Apple IIes and IBMs.

Web designers with good taste in colors and fonts often make more money than weightlifters, triathletes, and the average Chinese speaker.

Nobody who is raising children is able to do those things in a year.

I know everyone is busy but the author provides the definition explicitly:

> And what I mean by taste here is simply the honed ability to distinguish mediocrity from excellence. This will be highly subjective, and not everyone’s taste will be the same, but that is the point, you should NOT have the same taste as someone else.

Concisely, discernment.

So your comment about “artistic quality” may apply. But from your ends sentence It seems you equate “artistic quality” to aesthetics , and I don’t think that’s what the author intended.

Wrong. ;P