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

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.

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

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

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

  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)

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

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

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.

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.

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

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

Also, relative line numbering changed my life.

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

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.

why not just?

    v<search>x

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

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.

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

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

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.

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.

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.

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.

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.