It's funny to see Helix mentioned, without kakoune being mentioned. Helix is a really nifty terminal editor. It aims to be nice out-of-the-box, to have good LSP support, DAP support, and Tree-Sitter support. Compared to vim's "action motion" keybindings, Helix goes for "motion action" (which kakoune popularised). I find this is frequently more intuitive. Helix also has neat discoverability.. with pop-ups showing you…
Vim Language, Motions, and Modes Explained (2023)
31–40 of 104 posts
Re: Vim Language, Motions, and Modes Explained (2023)
#32A sad thing is that many people still believe that Vim is something mosty outdated and it’s hard to make it as useful as VS Code. But in fact it’s pretty much the opposite. I also think that the infamous steep curve is not so steep in reality.
Re: Vim Language, Motions, and Modes Explained (2023)
#33Here come the "[..] anyway I'm happy with VSCode" comments
I feel like those trying to teach me Vim are the same who refused to learn to use VsCode. Once configured, I can do the same than Vim. With more features.
It also can't run in a terminal, as far as I know.
Re: Vim Language, Motions, and Modes Explained (2023)
#34I've tried Vi/Vim key bindings on several occasions, but just couldn't be efficient in it. It's often touted as the "superior" form that confers benefit to those who invest time to learn it, but discussions with other coders have led me to believe this is just confirmation bias by people who prefer these key bindings. There are people like myself who edit frequently while writing (even with in a single sentence or wo…
I don't think it's the keybindings in particular that people love about vim, you can rebind everything after all. I'm attached to vim keybindings in the same way I'm attached to qwerty keyboards - something had to be the default, it's fairly arbitrary, and there's very marginal benefits in switching to a different set of bindings. It really is the modal editing style that's the main draw. Someone who edits frequently…
Re: Vim Language, Motions, and Modes Explained (2023)
#35I've tried Vi/Vim key bindings on several occasions, but just couldn't be efficient in it. It's often touted as the "superior" form that confers benefit to those who invest time to learn it, but discussions with other coders have led me to believe this is just confirmation bias by people who prefer these key bindings. There are people like myself who edit frequently while writing (even with in a single sentence or wo…
I use both Vim and Emacs, extensively, so I'd just like to share my experience with mode switching in Vim. Personally, I don't find Vim mode switching to be much of a problem while editing text. It has become muscle memory to stay in normal mode by default. After any insert-mode operation, I instinctively return to normal mode. It's just a habit at this point. Take, for example, writing a for loop. I might type: for…
I have been using Emacs for about 6 years now and when I fail to engage a modifier key properly all that happens is that I type some text in the active buffer. If I really manage to do a silly mistype, I can just hit C-h l to show my recent keystrokes to find out what I did.
Re: Vim Language, Motions, and Modes Explained (2023)
#36I've tried Vi/Vim key bindings on several occasions, but just couldn't be efficient in it. It's often touted as the "superior" form that confers benefit to those who invest time to learn it, but discussions with other coders have led me to believe this is just confirmation bias by people who prefer these key bindings. There are people like myself who edit frequently while writing (even with in a single sentence or wo…
I use both Vim and Emacs, extensively, so I'd just like to share my experience with mode switching in Vim. Personally, I don't find Vim mode switching to be much of a problem while editing text. It has become muscle memory to stay in normal mode by default. After any insert-mode operation, I instinctively return to normal mode. It's just a habit at this point. Take, for example, writing a for loop. I might type: for…
> for (int
> Then, say, I pause briefly to think about the variable name. If you happened to look over my shoulder at that moment, you would find me in normal mode.
I personally wouldn't but that's only because even in the case above I think in the same way as you mentioned next:
> I just see it as a single action in normal mode that includes the key sequence "i a b c ESC".
in the sense that I will ESC only after I have instered a "semantic-ish unit", which would include the variable name.
So I'd probably enter:
i for (int foo; foo
and think there (and finalise with ESC N . N .)Re: Vim Language, Motions, and Modes Explained (2023)
#37I tried vim motions as a daily driver many times but, I don't think that with today's expansive IDEs vim motions are all that superior. IDEs have very competent shortcuts and features built in. My biggest problems with vim are lack of feature discoverability and the fact that you can't change the keybindings. It's very hard to learn new things in Vim without specifically googling for them. It's highly likely that if…
To me, learning vim is like learning a musical instrument. You’re not going to get there without committing to it. For many people that’s just not going to happen: they have neither the time nor the inclination/energy to do it. That’s totally fine! There are loads of other tools for people to use and they get by just fine without vim!
I think my main complaint is that there aren’t a few more tools like vim. Almost all software is designed for people to be able to pick up casually and be able to get work done at a passable level of productivity without ever reaching mastery and flow state. Tools like that (easy to use but with no real incentive for mastery) are deeply unsatisfying to me for a lot of reasons.
I guess what I’m saying here is really just a restatement of “Worse is better” [2].
[1] https://www.oreilly.com/library/view/learning-the-vi/1565924...
Re: Vim Language, Motions, and Modes Explained (2023)
#38It's funny to see Helix mentioned, without kakoune being mentioned. Helix is a really nifty terminal editor. It aims to be nice out-of-the-box, to have good LSP support, DAP support, and Tree-Sitter support. Compared to vim's "action motion" keybindings, Helix goes for "motion action" (which kakoune popularised). I find this is frequently more intuitive. Helix also has neat discoverability.. with pop-ups showing you…
One thing that's slightly frustrating is the key binds are running interference in my brain with the vim keybinds. Especially the x/d swap. It might be because I still use vim keybindings in other programs, but I find I'm now also worse at vim than I was before I started helix.
The discoverability is definitely a big nice feature, I definitely use more e.g. tree-sitter motions because I can actually remember them unlike in my plugins in nvim.
Re: Vim Language, Motions, and Modes Explained (2023)
#39Yes, it’s super handy to be able to record an Emacs macro and modify large text within seconds, something that would take me half an hour. Yes, it’s super cool to navigate text at lightning speed. But honestly, I have seen engineers who work with the mouse to navigate, and use nano to edit text in the terminal, and IDEs from intelliJ to navigate their codebase, engineers who were 10x as productive as I was. Why? Beca…
I really enjoy precision, and that's what vim provides. It's the same reason I'd much rather play an FPS video game with a mouse and keyboard, than an analog control stick. And the same reason I hate doing anything important on a touch screen.
Re: Vim Language, Motions, and Modes Explained (2023)
#40I tried vim motions as a daily driver many times but, I don't think that with today's expansive IDEs vim motions are all that superior. IDEs have very competent shortcuts and features built in. My biggest problems with vim are lack of feature discoverability and the fact that you can't change the keybindings. It's very hard to learn new things in Vim without specifically googling for them. It's highly likely that if…