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.
> 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 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++. :)
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!)
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.
- 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 :)
> 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
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)
> ...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.
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 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.
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.
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!
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.
First would type out a few lines of code incredibly fast with lots of mistakes (and not bothering to backspace over wrongness) - then go back and clear up damage using notepad level editing.
Second would stare fixedly at screen for several seconds, whilst remaining still as a statue, then carefully emit the minimum string of editing commands to achieve the change.
Their actual rate of progress was pretty much identical.
> Second would stare fixedly at screen for several seconds, whilst remaining still as a statue
That eliminates many of the benefits. Was your coworker relatively new to Vim? Or maybe pondering what change to make, not how to actually make it? This is what I've seen from a coworker who was learning Vim and forcing themselves to learn the "proper" way to do things. I don't consider that to be a bad thing, provided that you balance it with actually getting work done.
I always do whatever allows me to edit the line without or with relatively short pause. That might be efficient vim commands, or it might be sloppy if the line isn't formatted in such a way that it fits my muscle memory. If I'm dissatisfied with the edit and think there might be a better way, I research it after the fact so I can later practice and know for next time.
This comes with experience; I've been using Vim for over a decade. Any pause in my editing is because I'm actually figuring out what change to make, not how to make that change.
Personally I'm extremely happy with the vim plugin in Jetbrains IDEs like IDEA, Rider and so on. It gives me the best of both worlds. I can use vim commands for effective navigation but also have the great static code analysis, smart auto completion, project navigation (find symbol, class, file, ...) etc. of the IDE.
Stripped of the vim baggage (yes, I know vim; yes, I stopped using it as my primary editor in the 1990's), it comes down to:
1. Learn to use the code navigation features of your environment (or get a better environment).
2. Learn to use incremental search and replace in your environment (or get a better environment).
4. Make autocomplete work in your environment (or get a better environment).
3. Make your often used actions one click or one command.
For (1) and (3), Visual Studio and IntelliJ are by far the best options available. (2) seems to be fine in any modern editor. For (4), acme is the best I've seen: you write your commands in a buffer, and click on the ones you want when you want them. If the buffer is a small one at the top of the window, it's the menu bar.
My dream is having an actually working/accurate to the character consumer-grade eye tracker that people can glue onto their screen. Then to move around in vim, look at where you want to go and just press a key.
I think this alone would allow for a jump in effectiveness almost as great as the jump from notepad to vim.
Selecting text with shift and arrows, moving across words with the control key and arrow keys, using home and end keys, using CTRL F and CTRL G, all those are already plenty enough for me.
I honestly don't understand why people use VIM or Emacs. I'm much more productive just with notepad.
Most editors can fold code block, use syntax highlight to make code so much more readable (if you take time to choose the right colors), highlight braces, autocomplete (even sublime text can do a weak autocomplete which is already quite handy).
To be honest, when you learn to type, using the shift, control, home and end keys should be the second thing you learn. Forget about vim and emacs, those were for times when people were coding over SSH. Use Nano if you're in a terminal. Also most of what coders do is read code, not write it.
Folks here assume "text editing" is just structured code editing. I use vim for more than just editing code trees in one language. I edit unstructured text (lists, notes, articles), semi-structured markup (latex, markdown), and machine-readable data that is not in the form of a tree (csvs, tsvs, scraper output, training data that comes in arbitrary formats).
The mindset I've come to appreciate for vim is that the goal is to have a zen garden for editing text. Editing text efficiently and seamlessly is the end goal, and what that text is used for is incidental.
I use AutoKey (Linux, surely there are similar apps on OSX and Windows) to do system-wide abbreviations, including correcting "teh" and "hte". Along with abbreviating a few common phrases, this probably saves me hundreds of keystrokes a day.
Anyone who is wary of trying out an editor like Vim should play dwarffortress for a bit. It's amazing how fast you pick up the keyboard commands for common operations.
One problem with key commands is that there's a lot of keyboard layouts. The same key can generate different letters depending on the keyboard. So when building an editor, do you listen to keys or whatever comes out after the key press(es) !?
It's true that you should think about what you're doing so you can avoid mistakes (and, as a side effect, type less), but you still end up typing quite a bit as a programmer, and you probably want to minimize the impedance mismatch while you're translating your thoughts into code.
I've seen this play out in real life with two programmers who were roughly equal in terms of thinking in abstract terms. One of them was much better at typing (and using tools in general), so their code quality was better overall. The other would get frustrated in the translation/typing stage and produce lots of sloppy and incorrect code.
[+] [-] jimmaswell|8 years ago|reply
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.
[+] [-] jonahx|8 years ago|reply
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)...
[+] [-] et1337|8 years ago|reply
Also try VsVim for vim key bindings inside Visual Studio. Or Sublime with vim bindings on instead of notepad++. :)
[+] [-] Rainymood|8 years ago|reply
>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!)
[+] [-] sevensor|8 years ago|reply
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.
[+] [-] Moogs|8 years ago|reply
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%...
[+] [-] shadowfiend|8 years ago|reply
- 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 :)
[+] [-] mrzool|8 years ago|reply
Your problem with Vim is that you don't grok vi:
https://stackoverflow.com/a/1220118/3078265
[+] [-] bananicorn|8 years ago|reply
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/
[+] [-] stanmancan|8 years ago|reply
Maybe I’m an outlier here but the whole thinking, planning, and experimenting takes way longer than my hands can move.
[+] [-] gumby|8 years ago|reply
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.
[+] [-] delta1|8 years ago|reply
[+] [-] alwillis|8 years ago|reply
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.
[+] [-] deathanatos|8 years ago|reply
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")
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] Tarean|8 years ago|reply
[+] [-] blfr|8 years ago|reply
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.)
[+] [-] alwillis|8 years ago|reply
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.
[+] [-] lanius|8 years ago|reply
[+] [-] rwallace|8 years ago|reply
[+] [-] garou|8 years ago|reply
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.
[+] [-] coliveira|8 years ago|reply
[+] [-] cryptonector|8 years ago|reply
[+] [-] swiley|8 years ago|reply
[+] [-] siissussjskk|8 years ago|reply
[+] [-] BatFastard|8 years ago|reply
[+] [-] cup-of-tea|8 years ago|reply
[+] [-] samlittlewood|8 years ago|reply
First would type out a few lines of code incredibly fast with lots of mistakes (and not bothering to backspace over wrongness) - then go back and clear up damage using notepad level editing.
Second would stare fixedly at screen for several seconds, whilst remaining still as a statue, then carefully emit the minimum string of editing commands to achieve the change.
Their actual rate of progress was pretty much identical.
[+] [-] mikegerwitz|8 years ago|reply
That eliminates many of the benefits. Was your coworker relatively new to Vim? Or maybe pondering what change to make, not how to actually make it? This is what I've seen from a coworker who was learning Vim and forcing themselves to learn the "proper" way to do things. I don't consider that to be a bad thing, provided that you balance it with actually getting work done.
I always do whatever allows me to edit the line without or with relatively short pause. That might be efficient vim commands, or it might be sloppy if the line isn't formatted in such a way that it fits my muscle memory. If I'm dissatisfied with the edit and think there might be a better way, I research it after the fact so I can later practice and know for next time.
This comes with experience; I've been using Vim for over a decade. Any pause in my editing is because I'm actually figuring out what change to make, not how to make that change.
[+] [-] fogleman|8 years ago|reply
[+] [-] bemmu|8 years ago|reply
[+] [-] tambourine_man|8 years ago|reply
7 Habits For Effective Text Editing 2.0: https://www.youtube.com/watch?v=eX9m3g5J-XA
[+] [-] bunkerbewohner|8 years ago|reply
[+] [-] madhadron|8 years ago|reply
1. Learn to use the code navigation features of your environment (or get a better environment).
2. Learn to use incremental search and replace in your environment (or get a better environment).
4. Make autocomplete work in your environment (or get a better environment).
3. Make your often used actions one click or one command.
For (1) and (3), Visual Studio and IntelliJ are by far the best options available. (2) seems to be fine in any modern editor. For (4), acme is the best I've seen: you write your commands in a buffer, and click on the ones you want when you want them. If the buffer is a small one at the top of the window, it's the menu bar.
[+] [-] pka|8 years ago|reply
I think this alone would allow for a jump in effectiveness almost as great as the jump from notepad to vim.
[+] [-] jokoon|8 years ago|reply
I honestly don't understand why people use VIM or Emacs. I'm much more productive just with notepad.
Most editors can fold code block, use syntax highlight to make code so much more readable (if you take time to choose the right colors), highlight braces, autocomplete (even sublime text can do a weak autocomplete which is already quite handy).
To be honest, when you learn to type, using the shift, control, home and end keys should be the second thing you learn. Forget about vim and emacs, those were for times when people were coding over SSH. Use Nano if you're in a terminal. Also most of what coders do is read code, not write it.
[+] [-] j2kun|8 years ago|reply
The mindset I've come to appreciate for vim is that the goal is to have a zen garden for editing text. Editing text efficiently and seamlessly is the end goal, and what that text is used for is incidental.
[+] [-] foxylad|8 years ago|reply
I use AutoKey (Linux, surely there are similar apps on OSX and Windows) to do system-wide abbreviations, including correcting "teh" and "hte". Along with abbreviating a few common phrases, this probably saves me hundreds of keystrokes a day.
[+] [-] joshvm|8 years ago|reply
[+] [-] paultopia|8 years ago|reply
1. "wow, the author seems to know a lot about vim!" 2. glance up at the name in the url ... ooooooh.
[+] [-] nnq|8 years ago|reply
[+] [-] raverbashing|8 years ago|reply
[+] [-] z3t4|8 years ago|reply
[+] [-] abakus|8 years ago|reply
thinking >>> editing.
If serious non-trivial editing effort is required, write a script to do it.
[+] [-] cname|8 years ago|reply
I've seen this play out in real life with two programmers who were roughly equal in terms of thinking in abstract terms. One of them was much better at typing (and using tools in general), so their code quality was better overall. The other would get frustrated in the translation/typing stage and produce lots of sloppy and incorrect code.
[+] [-] ouid|8 years ago|reply
[+] [-] altestova|8 years ago|reply
[+] [-] mmirate|8 years ago|reply
[+] [-] miguelrochefort|8 years ago|reply
[+] [-] ndh2|8 years ago|reply
1) Observe other people edit text, then judge for yourself what is effective and what isn't, then decide for yourself what to learn and what not to.