Hacker News Reader

Comment by jimmaswell | Hacker News Reader

I've used vim quite a bit but it still never beat GUI editors for me. The lack of a mouse cursor was always a pain point - for example simple copy/pastes take notably longer. Moving a block of code below another block of code takes 1 second in notepad++ while in vim you have to go V 10d x 13down P or something along those lines, figuring out exactly what numbers to use there probably takes more than 1 second alone. It always feels claustrophobic editing a file in vim, like I'm having tunnel vision, and jumping around files to understand the structure of a program or write a feature that changes many things is more time consuming, and pgup/pgdn and arrow keys just aren't as good as a scroll bar.

Overall I'm glad vim exists so editing config files remotely is easier if I don't have the server mounted locally - it's definitely my favorite shell text editor so far but I'd take notepad++ or visual studio over it any day.

View on HN

> Moving a block of code below another block of code takes 1 second in notepad++ while in vim you have to go V 10d x 13down P or something along those lines, figuring out exactly what numbers to use there probably takes more than 1 second alone.

    dip}p

which would be pure muscle memory to an experienced vim user, and certainly faster than doing it with a mouse.

Vim isn't for everyone, but I mean, it's not really fair to criticize something because you don't know how to use it well yet (though complaining about the learning curve would be reasonable)...

I didn't mean just blocks of code that would be recognized as a paragraph or are fully enclosed in brackets or anything like that. I mean moving some lines around possibly within the same function, which may or may not have multiple newlines between some of them, and have no lexically distinctive property aside from being the lines you want.

It’s still just a few keystrokes.. 10dd 5j p. Take 10 lines, move down 5 lines, paste those 10 lines. With relative line numbers in the gutter there’s no counting involved either. The whole thing is faster than even just reaching for the mouse.

How far away is your mouse?

As close as you like. Mouse movements are much more finicky than keyboard ones -- they require a physical precision (seeking, alignment, selection) that keyboard movements don't. And if you never leave the keyboard, you don't have to return to the keyboard to continue your typing. I'm confident even a moderately skilled touch typist familiar with vim would outperform someone switching to the mouse on average for these kinds of tasks.

I would be very interested to a) see this claim tested b) see if it makes a difference in productivity. (Most of what makes me slow at work is trying to understand technical problems, not trying to find parts of text in my editor.)

> Most of what makes me slow at work is trying to understand technical problems

That's me too. I spend a lot of time each day reading and that's a lot of scrolling with my mouse and ctrl-clicking on works to jump to definitions or declarations. Text editing speed is definitely not a bottleneck for me.

> I would be very interested to a) see this claim tested

I would too. But I'd be willing to wager on the results beforehand.

> b) see if it makes a difference in productivity. (Most of what makes me slow at work is trying to understand technical problems, not trying to find parts of text in my editor.)

There's no doubt that things like understanding technical problems, avoiding procrastination, and many non-technical factors are the high-order bits of productivity.

That said, the context of this conversation is text-editor optimization. Also, I think the true benefit of an optimized text editor isn't in raw time savings but in increased flow and just the joy of having a tool that feels like the extension of your mind, rather than something your mind works around.

> Also, I think the true benefit of an optimized text editor isn't in raw time savings but in increased flow and just the joy of having a tool that feels like the extension of your mind, rather than something your mind works around.

I couldn't agree more. For me, that's working with a Logitech Anywhere MX mouse in Sublime Text. I imagine how I want the text on screen to be transformed and it just happens without conscious thought.

Anything special about that particular mouse that makes it good for editing with ST?

No. It's just the mouse I've been using for a long time now. It's small, I'm used to how it tracks and accelerates, it fits my hand, and you can disengage the click mechanism on the scroll wheel to spin it freely.

My big complaint is that the buttons eventually start to fail. Single clicks will sometimes register as double clicks and click-drag operations start to drop early.

My thoughts exactly (although mine might not have been worded that well :) ).

Vim-bindings are like a REPL, but on a different level. If you compare a REPL to a loop of "save, compile, run, enter passwords, wait for a specific event to trigger", you might get a grasp of what a Vim-enthusiast gets out of the editor. They've fixed the thing to fix and moved on while you're still trying to find out where your mouse movement went.

That might sound a bit exaggerated, but for the skeptics, I propose an experiment: Switch your keyboard to a different language (say Turkish, if you're very brave) and try to code for a couple of minutes. I do that regularly (my colleagues don't use the same layout as me), and I'd wager it's about the same level of annoyance as not being able to use Vim-bindings if you're used to them.

I'm not saying that there aren't other effective ways of editing text, I'm merely finding that the defaults aren't very good.

While not a direct test, there's prior research into the fact that folks who use keyboard shortcuts think they're faster than their mousing counterparts---and are wrong:

http://www.asktog.com/TOI/toi06KeyboardVMouse1.html

> We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:

> - Test subjects consistently report that keyboarding is faster than mousing.

> - The stopwatch consistently proves mousing is faster than keyboarding.

(PS and caveat emptor: it's now 30 years since that study was done. Also, I personally firmly enjoy my vim. I just try to stick to liking it because I like it, not because it makes me an uberuser. An uberuser will probably be an uberuser no matter what.)

I still think this might hold true. But for me mouse (and touchpads, trackpoints) trigger repetitive stress syndrome - so acme isn't really an alternative - yet.

But I have some hope for merging the ideas of acme with proper touch screens/digitizers.

Ugh, I don't know, a lot of things could skew that result, from font/button sizes (it's hard to miss if you could only fit 5 lines of text on your screen) to insane shortcuts to memorize (I mean c'mon, ⌘-⇧-4 to take a screenshot? There's a line or two about that at the link, but it's presented like inferior and ambiguous combinations are the only one that UI/UX folks can come up with) to ergonomics of the input devices themselves (some cannot stand chiclet keyboards, some can be really productive with trackpoints—sure, this doesn't sound anything like pre-1989 Apple but you get the idea) to even cursor speed/acceleration curve settings. That being said, I'd like to see some details on that R&D.

Also, the poor experimental design and lack of peer review about casts some doubt, really.

It depends on how much you do the activity.

When I was a DBA, I did all sorts of data normalization stuff, and the Unix pipeline of tools (vim, sed, awk, some perl) was necessary and I was adept at it. Today, I don't do it that often, and it's quicker to just use Excel or whatever for slicing and dicing. It's not worth the overhead to save 10 minutes of manual tasking.

You'd see this when you did green screen to web transformations in enterprise projects. Training would 1/10 the effort, and knowledge based processes would be faster, but the new people would be alot slower than the veteran keyboard operators.

Have you tried a trackball mouse? That was the magic 'ah-ha' moment for me. I haven't used a normal mouse (at work) in probably 6 years or so. I find in speed it is trackball + kb > kb-only > normal mouse + kb.

But cursors don't imply mice.

With cursors you just hold shift and use down-arrows to (visually) select the lines you want. Add in Ctrl and you can move word-boundaries, add home-end and you can do beginning/end lines / pages too.

The whole thing is still quicker than vi but with the added benefits of getting much more visual feedback on what is happening and the ability to use the mouse to also quickly select things.

Add to that by example sublime text Ctrl shift up to move the selection up one line. Really hope other editors would just take sublime key mappings

selecting something and hitting dP (potentially kdP) will do the same thing in vim

In sublime text you don't need to select anything, ctrl+up/down will move the whole current line up/down.

Sounds like Visual mode

I'm not super good with movements myself, so I just use visual mode and the movements I know to select what I want. It doesn't take me longer than reaching for the mouse and moving it around most of the time.

I used to share your sentiment but kept going with vim for a year, and now I'm spoiled. Any time for some reason I am forced to use a GUI and a mouse, everything just feels so slow to me now.

Same here. Even if I'm forced to work with non-Vim tools (Visual Studio for example) using their often incomplete Vim-emulations makes lightyears of a difference.

If I had to "criticize" one of Vim's concepts, it would be its way of overriding registers in very unintuitive situations, but I'm certain I'll get used to that, too. When you're aware of it, it's simple to avoid using "_ first.

Edit: OTOH, selecting a piece of text and replacing it with p is quite irritating: The 0 register will still contain its original data, but " will contain the replaced text. I am not aware of how to disable this effect ("_p will paste from the black hole register, which doesn't help in this case).

Or switch to Visual Line mode (<shift>+v) to select desired lines and you don't need to count how many lines to delete/yank.

Another useful visual mode is Visual Block (<ctrl>+v), for deleting/yanking, replacing block across multiple lines.

That's exactly what jimmaswell suggested he didn't like, though.

I see, I thought he had problem with counting line numbers to delete :)

I'd make a few counterpoints there:

1. Even in those situations, I believe a veteran vim user would still beat someone using a mouse.

2. That said, the situation you describe is relatively rare: when coding you typically will be addressing blocks of text defined as functions; sharing an indent level ("ii" selects these); or otherwise selectable by vim in 2-3 keystrokes.

3. Even when that's not the case and the vim selection takes, say, 5 or 6 keystrokes, it has the advantage that your fingers never left the home row, so there is no wasted time "resetting."

4. Just as a tip: doing a "/" search for 2-3 characters after making your visual selection is typically enough to define your block, and will often be faster (and less of a cognitive distraction) than trying to eyeball or count the number of lines and doing a "10j" motion or similar.

> sharing an indent level ("ii" selects these)

That doesn't seem to work. Am I missing something?

I'd forgotten that I get this feature from a plugin:

https://github.com/michaeljsmith/vim-indent-object

I've been eyeballing the number of lines (or characters) long enough that I am correct more often than not.

Also, relative line numbering changed my life.

put a marker at the begining of what you want to cut (mb) b is an arbitrary character but I use b becaues b = begin. find the end of the block with search, or jkl; or whatever. mark the end of the block (me) e is for end. now type `b, that will bring you back to the start. type v, that puts you in visual mode. type `e, that selects your text from begin to end. x to cut it.

so all in all it's mb<search>me`bv`ex

now if your say you can search your text faster with your mouse than with keystrokes you have a different problem: you don't know how to use the search features in vim efficiently.*

I think it's nearly impossible to be faster with a mouse than a keyboard when it comes to search.

*and yes, to be efficient at it there's a 2 month learning curve that pays dividends over the next 30 years of your programming career -- it's up to you if you think it's worth the investment or not. Use it or lose it, if you don't make an effort you'll stay at your local maximum.

> so all in all it's mb<search>me`bv`ex

why not just?

    v<search>x

Just another suggestion. sometimes visual mode is overwhelming, or you don't want to be in it while your search for the end of the selection without being sure where it is. Another thing is if you start with line visual mode (V), and then you end up not wanting line selection the markers help you out -- it's a finer-grained set of commands that's a bit more flexible and a bit less efficient.

^ Hey so for the novice to moderately experienced users, this actually works and is composed of three commands:

  dip   => Operation - delete (cut) inner paragraph

  } => Movement - go to end of paragraph (the end of the paragraph following the one you deleted)

  p => Operation - paste (the paragraph cut using delete)

Edit: Removed 'not sure why dip copies'; Thanks for the TIL PaulBGD_ !

Some other cool diX (delete inner X) commands here: http://vimdoc.sourceforge.net/htmldoc/motion.html#diw

dip copies because d isn't delete, it's cut.

That makes sense, thanks.

Well, the mnemonic is delete, it just also puts the deleted text into your clipboard

Since we're talking about pedantry and how it relates to users learning and using vim, let's talk about clipboards. Your clipboard is the '+' register. Cutting or yanking text does not put it into the '+' register, but rather a specified default local register (is it normally 0? Somebody feel free to correct me here). As a consequence, if you delete or yank some text, it doesn't go to the clipboard. If you really want it to go to your clipboard, specify '+' as the default register or call di"+p in place of dip.

This naturally confuses beginners because the concept of registers is completely foreign to other editors. Emacs can provide similar functionality, but by that point Vim is no longer in "weird" mode compared to what you know. We do a lot of simplification when talking about Vim, but small points like this can be immensely confusing for people who just want something to behave the way they're used to.

The default register is unnamed:

> The unnamed register is the default and holds the most recently deleted or yanked text; it’s what’s called upon when you just type p without specifying a register.

Source: https://pbrisbin.com/posts/vim_registers/

Besides + there is also * for accessing alternate clipboard: http://vim.wikia.com/wiki/Accessing_the_system_clipboard

> it's not really fair to criticize something because you don't know how to use it well yet

I don't see any criticizing, just "it doesn't work as well for me," which I think is entirely fair.

In particular, it seems like 'jimmaswell prefers an editor where you think of blocks of code as "I can see this on the screen" than "up to the end of the current curly brace," which seems like a legitimate difference in mental processing styles, not a consequence of lack of learning.

I've been using vim as my only code editor for probably 10 years now, and dip}p is foreign to me. I'd do it by using /{ to search for the beginning, using Ctrl-V /} or /^} or something to search for the end, then using d and searching again for the place I want to insert it with p.

(Also, I think { and } don't work if you're using Python, whereas "I as a human can understand the structure of this code and identify the beginning and end of functions, which I already do because I'm literally writing code in this language" is portable between languages.)

> I don't see any criticizing, just "it doesn't work as well for me," which I think is entirely fair.

I had no problem with his tone. But he's very much making a statement about a technical problem he has with vim, and which isn't well-founded.

> In particular, it seems like 'jimmaswell prefers an editor where you think of blocks of code as "I can see this on the screen" than "up to the end of the current curly brace," which seems like a legitimate difference in mental processing styles, not a consequence of lack of learning.

There is nothing about vim that impedes a visual mental processing style. I constantly look at a place I want to select and then jump there using any number of methods -- the easymotion plugin is ideal for this.

> (Also, I think { and } don't work if you're using Python, whereas "I as a human can understand the structure of this code and identify the beginning and end of functions, which I already do because I'm literally writing code in this language" is portable between languages.)

Again, even vanilla vim performs better here than a mouse. But you should really have custom text objects installed for any language you work in regularly. Here's one for python: https://github.com/bps/vim-textobj-python

Thanks for plugging easymotion. I regularly use a similar feature provided by the VimFx Firefox add-on, but never bothered to look for a way to move similarly inside Vim itself.

I find vim sneak better than easy motion: https://github.com/justinmk/vim-sneak

This is so popular, it made it to emacs too: https://github.com/hlissner/evil-snipe

I love the 2 char lookahead/lookbehind. It is so fast and useful.

Thanks for the rec. What are the advantages of vim-sneak over easy motion?

Very late responding, but some advantages are described here: https://github.com/goldfeld/vim-seek

I had those issues very early on. Forcing myself to do everything in VIM solved it. It's just muscle memory that people are lacking, once you don't have to think about how to indent/move/select/yank and it is an unconscious action: all these difficulties cease to exist.

Pendantry: IIRC `{` and `}` work on paragraphs (or contiguous blocks of lines up to the next blank line) rather than code blocks by default. I'm sure it's possible to change that, but once you're changing things there's no reason not to add support for Python indents or Ruby style `def`/`end` blocks as well.

Like you I also generally just use searches or `%` most of the time.

Not pedantic at all, tbh. This is an important distinction. Curly braces are my primary way of moving in vim and it works great even without curly braces in the code (even in pieces of code without delimiters, actually)

Do you also use something like bde instead of diw, and ?(ld/)<CR> instead of dib? And if the answer is no, how is dip not in your vocabulary after 10 years?

> where you think of blocks of code as "I can see this on the screen" than "up to the end of the current curly brace," which seems like a legitimate difference in mental processing styles, not a consequence of lack of learning.

I see this a lot. I tend to think of things visually, be it abstract concepts or code. I remember code by how it looks on screen and how it fits together conceptually, rather than the words. I remember the "shape" of pages of specific papers I read 30 years ago that influenced me, but not the precise words - both literally (I remember what the text looks like and how it was laid out on the page) and conceptually (the takeaway of specific "shapes" of text).

To me this seems like a major difference in thinking that alters the type of languages I prefer. E.g. Haskell to me is noise. I can sit down and decipher it. I read many of the original Haskell papers, and implemented my own lambda calculus implementation etc. to try to get my head around it, and many of the concepts stick with me, but the language is too visually messy for me.

I think this distinction of thinking about symbols vs. visual layout is very pervasive.

I think the same way. That is I am extremely visual and remember visual things very well, though like you its more often the shape of it rather than the specific content, depending.

I grew up using Windows though and while I have had to use vi/vim for work and personally before, I dislike it with a passion (due more to that I didnt grow up using it / havent used it extensively im sure). Ill share the linux folder to windows and use Notepad++ when I can lol.

There are basically three parts to the command

> dip

Delete in paragraph. Command+text object is probably the most frequent pattern in vim for me. It would also would work with other text objects like `di(`, `di{`, `di[` to delete between (...)/{...}/[...] bracket pairs for instance. Or other commands like `cip` for change, `yip` for yank(copy) and so on.

Plus custom text object and commands which give exponential combinations. My most used are `ii` or `ai` for in/around indentation, `s` for surrounding and `gc` for toggling commenting in an area.

`{`/`}` go up/down paragraphs. If the code isn't densely packed this works pretty well to jump between logical sections. For c-like languages there are a bunch of weird jumps like [[ and ]] which you were probably thinking of, they are configurable but don't seem very useful.

p means paste which you probably now anyway.

which would be pure muscle memory to an experienced vim user

As selecting some text with a mouse would be for anyone who's ever edited text with a computer. It's hard to see this kind of argument as more than a statement that learning arcana can be enjoyable. It's true, but then you might as well be learning Rust or writing a tutorial on understanding monad tutorials.

What if your block isn't denoted by curly braces but just indentation?

I feel the exact opposite. Reaching for the mouse and aiming the cursor takes forever. I almost never use number prefixes like "10d" for the same reason you dislike them. There are so many other options. } to skip to the bottom of the paragraph, % to skip to the end of the block, H/M/L to target a position on screen, / or * to navigate by searching, Ctrl-D to scroll down half a screen...

Also try VsVim for vim key bindings inside Visual Studio. Or Sublime with vim bindings on instead of notepad++. :)

>I've used vim quite a bit

>pgup/pgdn and arrow key

Then you should start learning how to use Vim, properly ;).

Start from the basics, work your way up. From your post it is painfully obvious that you don't really use Vim to it's fullest potential. Vim requires a completely different way of thinking than regular text editors, and, it requires time to learn.

Only use up down with kj for fine movements. Large movements happen with gg, G, preset marks, and <C-d> and <C-u> which are half screens down and up for me respectively. That covers vertical movement. Most of my horizontal movement is done with either f or vim-seek (which is like f but takes 2 characters!)

Also very useful is setting "number" and using :123 to jump to line 123. This helps the most with compiler errors, but it can also help if you've got a lot of lines on the screen.

123G (saves you one “return”, which is an annoying key.)

123gg saves a shift :)

I think, because you're used to it, you're under-estimating the cognitive overhead of using the mouse. It also sounds like you've bought into some of the worst kind of vim evangelism, the kind that says effective vim users never hit j repeatedly to move between lines. Granted, it's not the best, but if you're moving only ten lines, V followed by repeated j takes basically no thought to create the selection. If it really bothers you, v followed by / will extend a selection to the match. I find that I mostly use / and ? to move around. In that context, setting hlsearch and incsearch might be helpful.

You might also want to use code folding, especially if moving blocks of code around is something you do a lot of. If you delete a fold in vim, the whole fold goes into the paste buffer.

What's the cognitive overhead? I'm a huge vim weenie and a pretty fast typist, but I'd never argue that the mouse is obsolete when compared to vim.

For example, I've played FPS games where I had to target something the size of < 10 pixels, in less than a second, and the need to move my mouse from one end of the mouse pad to the other. Basically, the mouse and (in most cases) cursor are barely separate from my body when it comes to pointing at things on the screen.

So when I need to put the cursor somewhere, I still find that using the mouse can be much faster than any vim key combination.

While I do agree that the 'context switch' from keyboard to mouse matters, I still find using a mouse/trackpad worth the relative effort often enough that 'pure' keyboard vim is a degradation in experience.

Reaquiring the cursor is an issue for me on systems that "helpfully" make vim mouse (or touchscreen) sensitive.

The cursor's where I left it, damnit. Don't move it and force me to put it back.

There are times when directly pointing to screen elements is useful. Working with text I almost always find it gets in the way

I don't think the mouse is obsolete, just that it's an obstruction when it comes to editing text. Vim, emacs, and my current favorite, kakoune, all give you a rich language for talking to the computer about how you want your text to be arranged. The mouse doesn't speak that language. It requires you to switch from thinking about text as text to thinking about it as a pixel target. That may only feel natural if you play a lot of FPS games.

While I do agree that when it comes to editing Vim/emacs/kaoune might be superior, I spend a nontrivial amount of my coding time in 'discovery' mode. scrolling, clicking around, and mouse stuff in general is very useful in that case, and in my experience definitely faster than keyboard-only.

I could try and make a nuanced argument of when and where a mouse is preferable to a keyboard, but I think even just scrolling is enough of an argument for me. CTRL-D or whatnot just doesn't do justice to scrolling with a mouse.

Anyways, mostly I'm a fan of Vim and using its approach as much as possible. I just get annoyed when Vim-fans try to argue that a mouse is never better, which honestly I feel is a the argument of a fanatic. I've never come across a remotely good argument as to why a mouse is never the answer, and it always feels like a needlessly 'partisan' type thing.

Keyboards are cool. Mice are cool. Can we all just get along?

EDIT: I got a bit carried away and I do agree more with you than this comment might suggest. I just think 'editing' is not the only thing I do when coding, and for some of that other stuff a mouse is a huge advantage, even in a coding context.

> I do agree more with you than this comment might suggest

Well spoken, that goes for me too. Something about internet discussions amplifies disagreement!

> Keyboards are cool. Mice are cool. Can we all just get along?

Agreed.

I'm a vim fanboy - and I use the mouse.

>Vim/emacs/kaoune might be superior

My google-fu is failing me; what is kaoune?

Parent probably meant Kakoune: http://kakoune.org

Indeed I did. Kak is great, especially if you find yourself often using visual mode in vim.

Re: scrolling, in vim you have CTRL-E and CTRL-Y and there must be a way to adjust the scroll step (usually 1) to the scroll step of your mouse wheel (usually like 3) is bound. Can a mouse do 30 scrollings per second (my keyboard input rate)?

Where the scroll wheel makes a difference is when you want to fine tune the scrolling speed, which you can't do with a keyboard. I don't think I have a usecase for that (but YMMV), and my impression is it often gets me out of text mode and into FPS mode.

What would be really nice for larger scroll steps (like CTRL-D) is smooth scrolling. I suppose there is no terminal support for this? Also gvim doesn't seem to have it.

Anyway I usually don't scroll by fixed amounts, but do * (identifier search), / (regex search), { and }, and maybe more.

EDIT: just added this to my vimrc. I don't think my mouse scrolling ever was this good

   " Triple scrolling "speed"
   nnoremap <C-e> 3<C-e>
   nnoremap <C-y> 3<C-y>

you also have ^f ^b (forward, back (by a page)), and ^u ^d (up, down (by half a page)). I honestly prefer scrolling by paragraph though ({ })

> That may only feel natural if you play a lot of FPS games.

Or almost any kind of PC games. There is learning curve to using a mouse, but it is quite short and once you're over the hump you can use the mouse without thinking about it. The cognitive overhead of the mouse is minimal. There are studies about this: http://www.asktog.com/TOI/toi22KeyboardVMouse2.html

"I've played FPS games where I had to target something the size of < 10 pixels, in less than a second, and the need to move my mouse from one end of the mouse pad to the other."

Do you type with just one hand? Because that's what you'd need to do to replicate that performance while coding.

If you type with both hands, now you have to add in the time it takes you to move one hand from the keyboard to the mouse, make the mouse motion (which could be far across the screen) and then back to the keyboard, repeating that cycle for every single operation which involves the mouse.

Meanwhile, someone who knows vim well and is not reliant on the mouse can type with both hands and only has to move their fingers.

I have my mouse right next to my keyboard (don't most people?). I can grab it about as quickly a I can press a key.

Even if that's true (which is doubtful, as the motion to press a key is much shorter than to move one's arm all the way off a keyboard to the mouse), then you still have the additional time it takes to move the mouse to where it needs to go, and then the time it takes to move your arm back to the keyboard.

There's no way that's going to be as fast. It's also going to be a lot more tiring, if you do that a lot, than merely moving your fingers.

This can not be overstated. I haven't seen many GUI type programmers programming in my live, but none of them was faster than "slow". I die of impatience when I watch them edit.

Sure, but you usually have to press a bunch of keys in just the right sequence to do the equivalent with the keyboard.

Some things are quicker to do with the mouse and some things are quicker to do using keyboard shortcuts. I don't understand why people take such absolutist positions on this.

My arm doesn't get tired from moving a few inches to grab the mouse.

"you usually have to press a bunch of keys in just the right sequence to do the equivalent with the keyboard"

Compared to a veteran vim/emacs user, you'd to do a whole ton of mouse movements to get the same effect of a few keystrokes.

"Some things are quicker to do with the mouse and some things are quicker to do using keyboard shortcuts."

The only things I've found to be quicker to do with the mouse are doing things like drawing in Photoshop/GIMP/Inkscape, or interacting with GUI applications which don't have keyboard shortcuts for most of their functions. Text editing and coding, on the other hand, tends to be much faster, sometimes exponentially faster, than the mouse.

>Compared to a veteran vim/emacs user, you'd to do a whole ton of mouse movements to get the same effect of a few keystrokes.

Depends on what you're doing. Again with the absolutism!

Tog (probably in “Tog on interface”) claims people overestimate the cognitive overhead of the mouse because it is so simple to use, and cites research showing it (including such examples as having to move the mouse over a large screen and back to access a menu item, compared to a keyboard command)

Using the mouse, he claims, is so boring that your mind has time to spend on other things, and that gets perceived as wasting time, while the keyboard continually requires one’s attention, making using the keyboard seem instantaneous

I think that’s why your advice to use repeated j instead of lower keystroke count alternatives is good.

And yes, his research is old (early 1980s) but it wouldn’t surprise me if it held even with die hard vim or meads users. Those keys you press may be close by, but you have to choose between tens of commands every time you issue an editing command.

I've read some of his stuff on this issue, and noticed his experiment design was atrocious, and he has 0 peer-reviewed research. So, I'm taking anything he says with a grain of salt. (I've been doing user research for over 15 years, in a different context, but still I've read tons of HCI/UX work, so I'm not just talking out of my ass here)

By and large, I think vim evangelism is deeply misguided, in that it asks you to learn too many things, it sees golfing your edits down to minimal keystrokes as something other than a total waste of mental energy, it encourages heavy plugin use, and it turns the vimrc into a whole program of its own. The whole point of using an editor like vim is that you don't have to think about it very much. Which is why I encourage using the basic movement and editing keys with reckless abandon. The only thing that justifies learning a new feature is that the simple way is deeply inefficient. Not just less efficient, but so terrible that it's wearing out your fingertips and leaving you annoyed. Global search and replace with regular expressions is a good example. Sooner or later, hitting the letter n and the period key over and over to repeat a replacement is going to get so tiresome that it's worth learning regex, but a novice user can go a long while before doing that and still be quite productive.

I put this in my ~/.xsession

    # keyboard autorepeat delay / rate
    xset r rate 170 30

It's tuned to my personal typing to be just slow enough that I never have accidental ddoublette kkeypresses, but fast enough that I can just hold down 'j' or 'k' in vim to move 10 or 15 lines (and easily hit the target). Using the mouse cannot even come close here (assuming you don't have your hand on it already). 15 lines would be 620ms here technically, so including the human factors it's still comfortably below a second. Really it makes a huge difference. (I saw this first in a talk by Edward Kmett).

> you're under-estimating the cognitive overhead of using the mouse

What "cognitive overhead?" And how is memorizing a bunch of arcane key combinations for cursor movement and region selection not cognitive overhead?

The (imo, dubious) argument against the mouse has always been that there's a strictly mechanical penalty for moving your hands around - not that there's "cognitive overhead."

> What "cognitive overhead?"

Let's break down the cognitive overhead of mouse use. Setting aside the "reaching for the mouse" penalty, there's a lot of work involved in mouse-related tasks like copying a selection:

1. Move your eyes off of the text you're editing so you can find the mouse cursor.

2. Figure out where the mouse cursor is relative to the text you need to edit.

3. Effect that relative movement with your mouse.

4. Highlight the text for copying.

5. ^C or some other key combo to yank the selection.

6. Reorient the mousing hand to the keyboard (find the home row keys again).

Steps 4 and 5 take an equivalent amount of mental effort, but 1-3 and 6 don't exist in vim. That's the cognitive overhead I'm talking about.

> And how is memorizing a bunch of arcane key combinations for cursor movement and region selection not cognitive overhead?

Visual selection is the letter v in vim. There are four keys for basic cursor movement. Then y for yank, d for cut, p for paste. Vim only seems arcane because so many posts about vim are really about demonstrating how smart the author is. I get pretty exercised about this because it's chasing people away who could really benefit from learning vim. Vim is not arcane, vim has a dead simple core with a bunch of entirely optional features on top of it.

> 1. Move your eyes off of the text you're editing so you can find the mouse cursor.

Try this: keep your eyes fixed on a character, then wiggle the mouse or trackpad. I don't think I ever actively look for the pointer before using the mouse, and I doubt anyone else does either.

I'm guessing that if you can track the mouse pointer without taking your eyes off the text you're editing, most of your listed steps become non-factors.

Vim does have support for mouse usage (depending on the terminal)[0]. You can add the following to your config:

set mouse=a

At that point you can quickly select text, hit "d" to cut it, click where you want it and hit p

[0] http://vimdoc.sourceforge.net/htmldoc/options.html#%27mouse%...

I knew about this but I assumed it couldn't be done through ssh/putty.

Not sure about putty but it definitely works over SSH depending on your terminal emulator.

It works through PuTTY, and moreover it's the default config in Debian 9, which I find sort of annoying because I'm used to using the mouse in PuTTY for copy/paste. But it does work smoothly (including through a screen session and through ssh to other machines).

Perhaps you should add an [edit] to your original post seeing as it's nabbed top spot and spawning several threads about lack of cursor support?

It works independently of transmission method since the mouse clicks are simply translated into "keyboard presses", i.e. encoded to stdin as escape sequences. It's a single stream.

Of course, the terminal emulator must play nice with the windowing environment and translate mouse events correctly.

What cannot be used through SSH/PuTTY is the IDE that you're comparing text-only Vim to.

One that runs on X can be tunneled.

I'd say two things here:

- Recent vim in terminal (and vim in a GUI container like gvim or MacVim) supports mouse interactions. For example, in macOS's Terminal.app, View -> Allow Mouse Reporting will send mouse events to vim, which will allow you to scroll with your touch pad, select with your mouse, etc.

- I think there is definitely a curve to learning many of the movement commands that vim provides to become fully efficient at moving, say, a block of code. When moving blocks of code, I most frequently use % (which jumps to the matching brace/bracket/paren) or } (which jumps to the next blank line).

I agree that it sometimes feels like there's an analysis step in vim interactions that can feel like it's slowing things down rather than speeding them up. In my experience, much of that calms down after you've been doing it a while. But, that doesn't mean it's worth the investment---I think that depends on the person.

I seem to editor-hop every 2-4 years. I generally end up coming back to vim for long stretches, but I've used plenty of other stuff in the past. I think if you feel productive, that's the tool to use. If you feel curious, or whatever, I think it's worth exploring. Vim is peculiar because its interaction mode is so different that it's hard to feel fully at home with it without going all in for an extended period of time and dedicating yourself to learning some of the stuff that's not necessarily immediately apparent. If you do that, sometimes you find it really clicks with you. Sometimes you don't :)

> - Recent vim in terminal (and vim in a GUI container like gvim or MacVim) supports mouse interactions.

...if by "recent" you mean a decade old version.

> Moving a block of code below another block of code takes 1 second in notepad++ while in vim you have to go V 10d x 13down P or something along those lines

Your problem with Vim is that you don't grok vi:

https://stackoverflow.com/a/1220118/3078265

There's a bunch of things you could try, btw: First off, vim has a GUI version where you can use the mouse (and in some terminal emulators you can too - for example st[0])

Secondly, did you try using splits (horizontal and vertical is possible, you practically have a sort of WM inside vim) or maybe you prefer the tabs-approach to things (even though the purpose of tabs is a different one, but you can bend it to your will so it works kinda like in notepad++)

Also, relative line numbers really help me with the vertical navigation - you practically have the number you need to type at the start of the line (and your current line can have the actual line number, if :set nu is active)

[0]https://st.suckless.org/

The whole argument of “wasting time” reaching for the mouse has never made sense to me. In a decade of programming its never been a bottleneck for me.

Maybe I’m an outlier here but the whole thinking, planning, and experimenting takes way longer than my hands can move.

You're not an outlier... The only time when editing takes longer than thinking is when you're processing textual data dump files in their various shapes and forms (logs, database dumps as SQL, etc.). For code thinking definitely takes longer than actually editing :)

It's not about wasting time, pointing devices are less precise which means they demand more attention and are less flexible.

Going with your theory, I'd say that pointing devices are more precise which means they require more brain-CPU cycles to operate ... pixel-space is large and you must position it within some delta of the target widget you're trying to use.

Whereas in emacs, say, it's a quick "C-x o" to change to the next/other buffer.

Right, they're more precise and less accurate.

I think it depends on the task at hand, whether you are jumping around or focused on a long piece; exploring or debugging ...

Anyway, not everything takes place in the editor.

"The acme user interface for programmers" (http://acme.cat-v.org/) is a good inspiration. It focuses on mouse usage and shows how most systems are as nicely integrated as they could be.

I have hacked together a setup that mimicks acme using a tiling wm, vim (and its amazing remote features), a plumber and a terminal that can send the current selection to the plumber. This way I use vim as I like but I can send it some path:line:col from anywhere with a right click.

Could you explain more about integrating acme ideas into a tiling wm, or possibly share your dotfiles? I've tried doing that with i3, but the window manager has less than optimal mouse support to say the least, and wmii is dead.

See https://st.suckless.org/patches/right_click_to_plumb/

The setup requires:

- a terminal that is aware of its shell current working directory (OSC7) (I use st or tmux and zsh)

- a terminal that would call a plumbing command with the current selection on a mouse right click (I use st or tmux)

- a plumbing command that would call the appropriate action given the selection string passed in (I use a script and plan9 plumber)

- an editor that supports being called from the plumbing script (I use acme or vim remote with vim-fetch plugin)

- an eventual tiling wm or tmux for window management

My dotfiles aren't public but I guess I could try and package them if you're interested. PM me at the email on the suckless page.

For me it's not about wasting time, it's that frequently switching between mouse and keyboard is a repetitive stress injury waiting to happen. The accumulated damage that can occur after doing it everyday for a few years really creeps up on you.

I concur. If you already have RSI like me (thank you Blizzard games), reaching for the mouse is literally a pain point already.

> ...it still never beat GUI editors for me. The lack of a mouse cursor was always a pain point - for example simple copy/pastes take notably longer.

Everybody's milage can vary; in my case it's 100% the opposite. Moving my hands off the keyboard is a demonstrable microinterruption.

FWIW I've been using both text and mouse-based editors since I was 14, roughly 40 years. Some of the time was in deeply mouse-oriented environments (e.g. Xerox PARC in the era when Stu Card was proving that the mouse is indeed a better input approach for a plurality of people -- so I'm not claiming that the mouse is a bad idea in principle). But the keyboard is just so much more direct for me -- I don't have to look at it, and often don't move my eye from the insertion point on the screen even when referring to something elsewhere on the screen.

In {G|Mac}Vim you can also use the mouse cursor and selection.

It also sounds like you don't have relative line numbers enabled, which makes highlighting or jumping some number of lines quickly pretty trivial: https://jeffkreeftmeijer.com/vim-number/

A Vim truism: if what you're doing requires too many keystrokes or otherwise seems cumbersome, there's another way to do it that faster and requires fewer keystrokes.

It's just a matter of whether you're interested in learning and not assuming you have it all figured out.

> while in vim you have to go V 10d x 13down P or something along those lines, figuring out exactly what numbers to use there probably takes more than 1 second alone.

Honestly, I usually just use 9j/9k[1] a bunch to get reasonably close / maybe overshoot a bit, and then adjust with j/k, using visual feedback to guide me. Much quicker than grabbing the mouse, IMO, or computing what line number to go to.

(Admittedly, I should really learn the "go to end of block/paragraph/etc. keys.)

You can also `set relativenumber`, which will change the line numbers on the side to be "relative" (that is, 2 lines down is labelled as "2"); this makes it obvious which number to hit.

[1]: (move down/up 9 lines, 9 being an arbitrary "several")

I really want to say `text objects are faster than using the mouse anyway` but it is probably worth noting that vim has mouse support, even in most terminals. It should be default in neovim. In vim it is disabled by default and the help says

    > Normally you would enable the mouse in all four modes with:   
    > :set mouse=a

so I am not entirely sure why exactly this has to be done manually.

Minimap. What I'm missing in all terminal editors is this neat overview of the file I'm editing.

Everything else can be achieved with clever keyboard shortcuts, tmux, or hacking the .vimrc. It's just a matter of time and persistence.

Similarly with mutt it's attachments. It just cannot handle them as well as a graphical/web mail client. (That and I mostly read my private email on the phone nowadays.)

The mouse works fine with gVim; I use the Magic Mouse with MacVim (the Mac GUI version of gVim) for scrolling through large files sometimes.

However, I never use the mouse in visual mode to highlight blocks of text; for that I'm much faster using Vim’s keyboard commands.

The individual user's keyboard and mouse proficiency determines their most efficient setup. I'm decent with Vim, but my mouse speed and accuracy is good enough to do many editing tasks with a mouse faster than I could accomplish in Vim.

How do you get moving a block of code to take one second in notepad++? I don't know of a way to get it to take less than a few seconds, but maybe I'm missing something.

I am not going to say "ViM is better".

Are you intended to keep using vim to edit these remote config files? May it be unnecessary, but if you want to try read this article to figure out how make these things faster using vim.

But IMHO if you are just going for it, there's no reason to learn vim.

It is a long path indeed, but wort it.

If I'm in an ssh shell and I want to edit a file, yes, I'll use vim. I've also done some coding in vim which is what I was mainly talking about.

Vim has had support for mouse for at least 20 years.

vim has mouse support, though I don't know anything about it since... almost the whole point of vim is to not use a mouse.

vim, tmux, and ssh have gpm support.

Maybe learn how to grok vim?

How do I select Lines 3, 16, 39, 50, 230, 420, 1302, and 2300 at random columns of my needs? With a mouse, I can cntrl/cmd + click the line I am interested in, wherever I am interested, and do any manipulation I want. Can VIM do this easily? I've never tried.

Maybe you're looking for visual block mode?[0] Or the multi-cursor plugin[1]? I haven't tried the latter, ut I really like visual block mode for certain things.

It's amazing how much new stuff I learn about vim every day... And I'm nowhere near done :)

[0]https://stackoverflow.com/questions/21806168/vim-use-ctrl-q-... [1]https://github.com/terryma/vim-multiple-cursors

it depends on what you want to do... but my general reflex is:

- go to line 3

- start recording a temporary macro ("qq" in my habits)

- do the editing

- stop the macro ("q")

- go to the line 16 with 16gg and reply the macro with @q - 39gg@q

- 50gg@q

- ...

this. Macros are something I've never used in other editors, but in vim they're simply... fun to use.

Well, if used for the right purpose.

And, in all earnestness: why are you doing that?

Is there something about those specific line numbers intrinsically? Is there a pattern or specific text on those lines? Is there a relationship to surrounding text, above or below?

The great thing about vim, or a set of similar tools (ed, ex, sed, awk, perl, cut) is that you can address the text in terms of the text itself. Search by text or regex, move within a line or between lines. Replace text or modify elements, preserving some and changing others.

Or, if I know in advance that I've got to deal with the 8 specific lines mentioned but without otherwise addressible context: 3G <edit stuff> 16G <edit stuff> ... 2300G <edit stuff>.

That's not elegant, but it's doable and fast.

Line numbers were irrelevant, just a set of random numbers. There is no pattern to the text (say it's a set of words that needs to be edited to become the same). I guess this is more related to working with large blocks of text rather than code. Someone mentioned macros, I'm going to give that shot.

What's the characteristc of the text and how do you identify it?

Again, search, paragraph and sentence navigation, and word nav are intrinsic to vim, and fast. If you know what you're looking for, "/<pattern>" and you're there. With incremental search ("set ic" in your ~/.vimrc) thats often a very few keystrokes.

What are you trying to accomplish with this? If you are trying to replace multiple cursors, the approach would be very different.

What I'd do is record a macro for the edit on one line into q, and then apply it to all relevant lines with a regex, e.g. g/regex/norm @q

Surely you'd agree that a mouse as an interface can provide benefit even in the context of a text editor?

Sure, but the question is if the physical and mental context-switch is worth this benefit. I'd say that in editors with a sufficiently expressive keyboard interface like vim, it is not.

One thing I still find myself doing in vim is using the scroll wheel. Browsing and editing is a context switch anyway and I think scroll wheels express scrolling a lot better than keyboards ever can.

Fair enough. I would definitely err on the side of vim when it comes to the benefits of staying within vim's 'mental model', because I do agree the context-switch does matter.

Furthermore, the fact that all my vim-context keypresses can be stored as a 'macro' in itself has provided enough of a productivity increase to make it all worth it. And this is even the case in less-than-perfect vim emulators.

And I do agree that for some things, scrolling and perhaps 'exploring' in general being a big one, a mouse can be worth the context switch.

siisussjsk might've been referring to doing a quick check to see if vim supports mouse as an interface… which it does.

Wow, shall we argue over whether tabs or spaces are better too? And after we solve that we can figure out how many angels can dance on the head of a pin!

Btw, the answer is "spaces" because tabs can be interpreted differently from editor to editor.

To take it a step further, its 4-space indents. I've seen code where people pull off 2-spaces, but it gets crowded failrly quickly.

> tabs can be interpreted differently from editor to editor.

You should ask a tabs advocate what they think the primary feature of tabs is :)

Both gvim and graphical emacs support mouse. But if you use it you're doing it wrong anyway. You're using your boot instead of a hammer because you couldn't figure out which end was the handle.

Reply on news.ycombinator.com