Show HN: Hardtime.nvim – break bad habits and master Vim motions

Funny, I was thinking exactly the opposite. Stack traces, logs, test failures, warning, etc will always reference an absolute number. If you want to tell a coworker where to find a section of code, you use the absolute number.

Relative numbers are useful to save a few keystrokes. But in every other context, absolute numbers are what's relevant.

> Interestingly enough, many games on PC standardized the WASD keys for moving, which might be seen as "left-handed".

To me, WASD for avatar movement makes sense even in the context of "right-handed bias" in that if a gamer is using a mouse, odds are they are right-handed and the mouse is positioned to the right of their keyboard.

And if a gamer is left handed, it's a minor inconvenience to shift the chair position such that their right hand manipulates WASD and their dominant left hand uses a mouse on the left side of their keyboard.

Of course, many modern games allow custom key bindings, so a left-handed gamer could use IJKL instead of WASD if they so chose.

C-d, C-u, {}, () and searches are better anyway. You should also be using g, so say you are defining a function and need to check where it's going to be used on main. For optimal usage you should always have main marked as something, so you would exit insert mode, gm, look around in main, gi to go back to where you were typing last

Not the parent, but I also tried to switch around two or three years ago and was very frustrated. The draw was the 'built-in LSP' with all these new features, along with treesitter.

'Built-in LSP' turned out to mean installing and configuring three pretty involved lua plugins at the time iirc. The experience really highlighted for me how un-seamless lua was in the project compared to vimscript. I found it to be a nightmare to configure and get used to. I came away wondering how it could possibly be such a pain, and baffled as to why it was claimed to be 'built-in' when getting ALE to work on vanilla vim took way less time, and felt way more in line with the rest of the program. Ironically it actually gave me an appreciation for vimscript that wasn't there before.

Eventually issues continued to kind of build up for me until I decided to just cut it. Everywhere I encountered lua felt crufty and difficult to work with, and those integrations made the concise, tight vim I'd gotten used to feel really nebulous and unweildy. I never quite got the treesitter syntax highlight to work correctly, and even when it did work having the highlighting dynamically change while typing frustrated me. I ended up slowly switching back to my old vim-compatible plugins one by one, until eventually I just went back to vim, since a lot of the neovim features that diverged from the original design philosophy bugged me and since I'd developed a strong aversion to anything involving lua in the program I wasn't getting anything out of using neovim.

It took me a dozen hours over few days, but I think I've finally made it. Aliased vim to nvim to force myself to use it.

However, this took way too long, and I've already deleted everything related to LSP and IDE-like features from kickstart, since I have IntelliJ for this, and I want to start fast. This might be totally missing the point of Neovim, so maybe I'm stubborn.

To be honest - mixed feelings. Everything works great after some effort, Telescope is cool, plugin ecosystem is amazing and active. But it is the small papercuts in the process that ruined the fun for me. It doesn't support 16-color terminals, so needs custom themes always. There is a Selenized theme available, but it fails to load as the main theme, I need to load another theme first and then reload that one, no idea why. Some of the colors don't load anyway (probably due to plugin load order), so I had to add an ugly `vim.defer_fn` to re-call highlights 1000ms after startup. What more, Telescope uses fzf for files but not for live grep, contrary how it works for Vim.

Also, there is a huge culture of not providing any keybinds by default, and instead configuring them manually, probably due to sheer amount of keyboard real estate already required by Vim, not to mention any of the LSP features or possible plugin conflicts. So many great plugins are useless with stock config (like blame.nvim) and really require forward thinking, how to put them under your keyboard.

I'll spend a few weeks there and see. Hopefully it gets better and better.