Comment by chongli
9 hours ago
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 paradigm: the primary purpose of vi was to extend the traditional line-editor ed (which was designed for editing through a paper TTY terminal) to full-screen interactive editing on a video terminal. Since early video terminals had very low baud rates, vi needed to be very efficient at reducing screen redraw. It just so happens that this emphasis is perfectly matched to the most common editing loop: jump to a location within the file and insert/delete/replace some characters. Thus vi happens to be perfectly optimized for this editing workflow and so I believe this is the reason for its enduring popularity.
The other task which vi is strong at (but which is otherwise secondary) is editing in the large: making multiple changes to a file simultaneously. This, I believe, is the primary strength of motion-action paradigm editors. In other words, they get it backwards! Thus they can’t help but annoy me while I’m working with their constant attempts to infer large-scale edits from my simple desire to jump around the file and make small changes. They are giving me a freight train when all I want is a car.
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)
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.”