Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vim Language, Motions, and Modes Explained (2023)

ssp.sh

Post reply on HN
Print view View original

71–80 of 104 posts

Re: Vim Language, Motions, and Modes Explained (2023)

#71

Post by eviks »

NalNezumi wrote: post #53
susam wrote: post #11

Earlier quoted context omitted.

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 think one (often forgotten) good advice to get used to the mode-switching is to move the ESC key to Capslock on the keyboard. It's tedious to learn to always go to the ESC key, upper left of the keyboard. Capslock is available from home row, and you should probably not use CAPSLOCK anyway, it's a bad practice. Put ESC key there instead and vim becomes wayyyyyyyy more ergonomic.

at most one y in way since Capslock is an unergonomic key in itself - it requires an unergonomic lateral movement of your weakest finger of your weaker hand

Re: Vim Language, Motions, and Modes Explained (2023)

#72

Post by msdz »

chongli wrote: post #54
rgoulter wrote: post #4

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…

I’m not a fan of motion-action. Most of the time in vi, all I’m doing is moving around. When you input a motion key in vi it moves you accordingly with no fanfare. The motion-action paradigm, on the other hand, primes the editor to expect an action. In many cases this leads to multiple cursors being left in your wake, which I find really distracting. I think this stems from a fundamental misunderstanding of the vi pa…

As someone familiar with Helix, I’m curious. Could you elaborate on this?

Because I’m not disagreeing with your point, I’m actually not getting it in the first place. How does jumping around affect your selection count? Which motion(s) are you performing that larger quantities of text are getting "selected" in the first place?

Re: Vim Language, Motions, and Modes Explained (2023)

#73

Post by danielvaughn »

palata wrote: post #29

I have been using vim for 15 years. I disagree with the idea that it makes me more efficient than someone else . First, because I have friends who don't use vim and are very fast. Second because most of my time as a developer is not spent writing/editing text. No, I love vim because of its ergonomics. If I use a mouse for too long, my arm/shoulder starts hurting. Maybe I could improve the ergonomics of my mouse (havi…

Do you modify your keyboard layout at all? I’ve tried Vim several times and many of the motions just feel awkward as hell for my fingers, but I’m on a standard wasd keyboard.

Re: Vim Language, Motions, and Modes Explained (2023)

#74

Post by rgoulter »

chongli wrote: post #54
rgoulter wrote: post #4

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…

I’m not a fan of motion-action. Most of the time in vi, all I’m doing is moving around. When you input a motion key in vi it moves you accordingly with no fanfare. The motion-action paradigm, on the other hand, primes the editor to expect an action. In many cases this leads to multiple cursors being left in your wake, which I find really distracting. I think this stems from a fundamental misunderstanding of the vi pa…

In terms of navigating around a document, the only difference between "motion-action" and "action-motion" is that with "motion-action", the cursor is a selection which highlights the last motion. -- I don't really find that to be a significant difference in terms of navigating around.

Instead, I'd say the biggest difference between "action-motion" and "motion-action" is that the latter lets you iteratively/incrementally manipulate the selected text. -- Vim supports this with its Visual mode. -- I think the main case for this is along the lines of "it's easier to use EEE in helix, than count out & input 3E in vim".

I'd agree for basic/small edits, "action-motion" is more efficient.

I think of helix's multi-cursor functionality as a rocket-powered chainsaw, though. :o)

Re: Vim Language, Motions, and Modes Explained (2023)

#75

Post by vasac »

NalNezumi wrote: post #53
susam wrote: post #11

Earlier quoted context omitted.

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 think one (often forgotten) good advice to get used to the mode-switching is to move the ESC key to Capslock on the keyboard. It's tedious to learn to always go to the ESC key, upper left of the keyboard. Capslock is available from home row, and you should probably not use CAPSLOCK anyway, it's a bad practice. Put ESC key there instead and vim becomes wayyyyyyyy more ergonomic.

For a win, replace Caps Lock with Esc when tapped and with Control when held.

Re: Vim Language, Motions, and Modes Explained (2023)

#76

Post by chongli »

lll-o-lll wrote: post #65
chongli wrote: post #37

Earlier quoted context omitted.

Yes, vim is not intuitive. It doesn’t teach itself to you. It takes hard work. I bought the O’Reilly vi/vim book [1] and read it cover to cover. I practiced a lot of things and was very deliberate about it. 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/en…

This “worse is better” is very interesting. Are you suggesting vi/vim is an example of “the right thing”, vs a “New Jersey” style?

Yes, though that characterization is time-relative. I think vi would’ve been called “New Jersey Style” back at the time it was created, owing to its legacy as a minimal extension to ed for full screen interactive editing on a video terminal.

Today, the editing landscape is dominated by IDEs which have very basic (nearly minimum viable) editing functionality in support of getting the product out the door ASAP and letting plugins handle the fine details. This stands in marked contrast to a legacy tool like vim which gets editing right out of the box, allowing people to be productive even with a stock configuration (no plugins needed, though of course many are available).

We might call this an analogue of the Overton Window: the TRT vs WIB Window has shifted so far towards Worse is Better that we now consider UNIX an elegant tool. The old team at MIT must be really disappointed now!

Re: Vim Language, Motions, and Modes Explained (2023)

#78

Post by chongli »

msdz wrote: post #72
chongli wrote: post #54

Earlier quoted context omitted.

I’m not a fan of motion-action. Most of the time in vi, all I’m doing is moving around. When you input a motion key in vi it moves you accordingly with no fanfare. The motion-action paradigm, on the other hand, primes the editor to expect an action. In many cases this leads to multiple cursors being left in your wake, which I find really distracting. I think this stems from a fundamental misunderstanding of the vi pa…

As someone familiar with Helix, I’m curious. Could you elaborate on this? Because I’m not disagreeing with your point, I’m actually not getting it in the first place. How does jumping around affect your selection count? Which motion(s) are you performing that larger quantities of text are getting "selected" in the first place?

I can’t speak for helix because I haven’t tried it, but I did spend a few weeks trying to get used to Kakoune before giving up and going back to vim.

The issue is that moving around would leave behind a trail of breadcrumbs. Sometimes these were visible cursors but other times they were invisible. Either way, I found myself being frequently surprised by the editor when it made changes I was not expecting.

Perhaps it’s something I could get used to with more time but it left me constantly perplexed and annoyed. I think ultimately what gets me is that in vim I can type a motion key and vim executes the motion and then returns to to a “null state” whereas with motion-action editors any time I key in a motion to jump somewhere I am now in the middle of the “motion-action” sequence and the editor is awaiting an action key to which it will eagerly respond. This to me feels very wrong, similar to the feeling I get when Siri is continuing to listen for more commands after invoking the command I asked for. Having to dismiss Siri all the time annoys the hell out of me.

Kakoune has a similar “dismiss key” which I remember pressing all the time out of habit, even when it was unnecessary, because the editor left me with this constant feeling of “unstable footing.”

Re: Vim Language, Motions, and Modes Explained (2023)

#79

Post by javier_e06 »

The dudes in the https://ytch.xyz Programming channel display their vim editors with all kind of plugins that make me jealous. Pure fireworks. There is a plugin feature that enhances the line number where your cursor is located in the leftmost column for line numbers and looks super cool. I wish I knew the name of that plugin/feature since I don't want to go into the trial an error.

I also use the vim plugin for Eclipse and MS Code in my Linux boxes.

Yet, when the shit hits fan ... its vim-console time baby!

Re: Vim Language, Motions, and Modes Explained (2023)

#80

Post by palata »

danielvaughn wrote: post #73
palata wrote: post #29

I have been using vim for 15 years. I disagree with the idea that it makes me more efficient than someone else . First, because I have friends who don't use vim and are very fast. Second because most of my time as a developer is not spent writing/editing text. No, I love vim because of its ergonomics. If I use a mouse for too long, my arm/shoulder starts hurting. Maybe I could improve the ergonomics of my mouse (havi…

Do you modify your keyboard layout at all? I’ve tried Vim several times and many of the motions just feel awkward as hell for my fingers, but I’m on a standard wasd keyboard.

I don't. I like to keep it as close as possible to the defaults so that it just works everywhere. I don't want to have to import my vimrc whenever I SSH somewhere :-).

I am on a standard qwerty keyboard, nothing fancy here either!

And I almost don't use vim plugins: I enable syntax highlighting, relative line numbers and I add CtrlP as a plugin. That's all. Whenever I need more than that, I start an IDE (configured with the vim bindings of course :-)).

Post reply on HN