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.
"The Idea" here I think is in the revelation of the ultimate preeminence of text in a programmer's life. Plain text deserves our utmost attention, yet many programmers overlook its significance and rarely give it deliberate thought.
"Text can convey ideas with a precisely controlled level of ambiguity and precision, implied context and elaborated content, unmatched by anything else."¹
Vim-navigation provides a mental and spatial "language" that enables efficient text manipulation through keyboard input. Rather than forcing your brain to process raw character chunks on the screen, it allows you to reason about text in meaningful units: letters, words, paragraphs, tags, nested structures - e.g., "delete everything between parentheses" - and more.
Sadly, we keep moving away from plain text conventions, making our work increasingly complicated. Have you ever tried quickly extracting text interwoven with code from Slack into your editor? Ever gotten mad when websites won't let you copy the content or use colors and fonts that make it unreadable?
I implore every programmer to reject the status quo and reclaim agency over text interactions - always find ways to deal with text on your own terms. For instance, I'm reading this thread and typing this very comment in my editor. Why wouldn't I? It has all the tools I need for it - vim-navigation, thesaurus, dictionaries, translation, etymology lookup, LLMs, and tons of other tools.
Final point: do not assume code is somehow different. Code simply is structured text. Don't try to find perfect "code editor", prioritize plain text. Good plain text editors are the best code editors, but even the most sophisticated IDE at some points brings mostly frustration if it cannot nicely handle the simplicity of plain text.
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.