Hacker News Reader

Comment by jonahx | Hacker News Reader

> 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)...

View on HN

> 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.

> 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.

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)

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.

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?

^ 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.

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

That makes sense, thanks.

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.

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.

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.

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).

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.

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 :)

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.

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.

Sounds like Visual mode

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.

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.)

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.)

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.

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.

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

> 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.

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.

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.

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.

> 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.

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.

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.

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

Reply on news.ycombinator.com