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