dip}p

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

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

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

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.

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.

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.

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>

Agreed.

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

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

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

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

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

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.

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.

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.

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.

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

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.

    # keyboard autorepeat delay / rate
    xset r rate 170 30

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

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.

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.

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

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

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

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

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

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

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/

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

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.

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.

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

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.

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.

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

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

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

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.

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.

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.

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.

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.

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

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

- 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

- ...

Well, if used for the right purpose.

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.

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