Why I can’t stop using Vim(kornerstoane.com)
kornerstoane.com
Why I can’t stop using Vim
http://www.kornerstoane.com/2014/06/why-i-cant-stop-using-vim/
168 comments
Do you happen to have some resources you can share? I've been playing with Tidal, a live-coding library and it wants me to use Emacs, and I just... can't. So any info on setting up evil-mode would be great, especially since it's fresh in your mind. I've found some resources but really don't know where to start.
I haven't dived into the details of Evil mode too much. The basic Vim motions and commands work out of the box, so for a casual vim user, it ought to be enough. I also went ahead and installed Evil-leader, so I could have the same <leader> keymaps that I have in my vim config.
A few places where I looked for small things here and there:
1. http://www.emacswiki.org/emacs/Evil
2. https://github.com/cofi/evil-leader
3. https://stackoverflow.com/questions/8483182/evil-mode-best-p...
4. https://github.com/mixandgo/emacs.d/blob/master/my-evil.el
5. https://bling.github.io/blog/2013/10/27/emacs-as-my-leader-v...
And I also got ido-vertical-mode so the emacs command buffer looks better.
Here's my setup: https://github.com/mgill25/emacs See user.el
Cheers!
PS: Some of the configuration needs to be set up before you activate certain modes - which is often implicit in plugins, so watch out for that. Eg: To emulate C-u behavior, the functions had to be put ahead of the (require 'evil) call in evil-leader.el
A few places where I looked for small things here and there:
1. http://www.emacswiki.org/emacs/Evil
2. https://github.com/cofi/evil-leader
3. https://stackoverflow.com/questions/8483182/evil-mode-best-p...
4. https://github.com/mixandgo/emacs.d/blob/master/my-evil.el
5. https://bling.github.io/blog/2013/10/27/emacs-as-my-leader-v...
And I also got ido-vertical-mode so the emacs command buffer looks better.
Here's my setup: https://github.com/mgill25/emacs See user.el
Cheers!
PS: Some of the configuration needs to be set up before you activate certain modes - which is often implicit in plugins, so watch out for that. Eg: To emulate C-u behavior, the functions had to be put ahead of the (require 'evil) call in evil-leader.el
I'm using stock evil mode with tidal on emacs. It's pretty good, but occasionally I'll open up a weird window. I used emacs in the late 90s, so I'm not completely afraid of it. I recommend that you shouldn't be either. You can use v to select sections and then just C-c C-c to run them. Nothing crazy. Navigate around with standard vim keystrokes, including the windows.
For that matter, getting SLIME w/ vim to work w/ Tidal wouldn't be the hardest thing. It's just that no one has tried.
For that matter, getting SLIME w/ vim to work w/ Tidal wouldn't be the hardest thing. It's just that no one has tried.
What problems are you facing? Setting up evil mode takes just what the emacs wiki says.
1. Install emacs. Start emacs. "Alt-x package-install" press enter "evil" press enter.
2. Open your .emacs or .emacs.d/init.el.
1. Install emacs. Start emacs. "Alt-x package-install" press enter "evil" press enter.
2. Open your .emacs or .emacs.d/init.el.
(require 'evil)
(evil-mode 1)
My favorite article these days on the differences between Vim and its composability and Emacs-style editors is "Why Atom Can’t Replace Vim”: https://medium.com/@mkozlows/why-atom-cant-replace-vim-43385....
It's unfortunate that, to me, the title implies there's something wrong with a person who still uses vim and nothing could be further from the truth.
Oh c'mon. Us vim users are seen as "those crazy people" by the majority of other programmers, and they have at least some point :)
I am the only person in my office that uses Emacs. Everyone knows vim. Everyone loves vim. You think you're the crazy one?
Jokes aside, outside of certain areas which are fairly unusual, most programmers have never used vim OR emacs and I would guess that most don't even really know about them. It can be hard to imagine in the echo-chamber that is the online tech scene, but really most developers just use IDE's and get on with life.
That's interesting. We all have our own circles we run in but every programmer I know uses vim or emacs except Windows users but, well, you know.
What I’ve noticed in the Boston/Cambridge area is a resurgence of interest in Vim. I’ve been to companies where they are intentionally using Vim and not an IDE, even though they could. They have repos on GitHub (like https://github.com/thoughtbot/dotfiles) where everyone pulls down the standard Vim and other dotfiles and goes from there.
I suffer from the same thing. I've gone even futher: I've customized my tiling wm to work with the vim keybindings; my file manager also works with those keybindings; I use vimperator, a firefox plugin, that has those keybindings...
There's a lot of stuff that I wish were better in vim, but, at the end of the day, it gets my work done better than anything else out there, so I don't have any reason to move away from it. It works amazingly well with tmux (otherwise, I would be using emacs + evil -which I actually use for Clojure-). And I'm pretty excited about neovim :). They are doing an outstanding job.
There's a lot of stuff that I wish were better in vim, but, at the end of the day, it gets my work done better than anything else out there, so I don't have any reason to move away from it. It works amazingly well with tmux (otherwise, I would be using emacs + evil -which I actually use for Clojure-). And I'm pretty excited about neovim :). They are doing an outstanding job.
Yep. Pretty much every piece of software that I write for myself or use I write or customize so that it has vim style modes and keybindings. Keyboard input is still the highest bandwidth human computer interface (voice can't quite make it because error rates mean that the bandwidth actually ends up being lower), and modality is an excellent way to reduce complexity and provide simple cues that make it easy to compartmentalize and remember lots and lots of useful commands.
"/ for searching (really, no other editor has made it this simple)"
Well, it's really esc-/ which is no easier than ctrl-f. Or am I missing something?
Edit:
Same with "1G to go to the top of the file, G to go to the bottom" - esc-1-shift-g vs ctrl-home. Same with ctrl-end.
Edit:
Same with "1G to go to the top of the file, G to go to the bottom" - esc-1-shift-g vs ctrl-home. Same with ctrl-end.
Or am I missing something?
Indeed you are. The / command in vim is a motion. This means it can be combined with any command that expects a motion as input. For one example of this, try typing "d/foo<CR>" (excluding quotes). This will delete all text from the cursor to the first occurrence of foo.
Indeed you are. The / command in vim is a motion. This means it can be combined with any command that expects a motion as input. For one example of this, try typing "d/foo<CR>" (excluding quotes). This will delete all text from the cursor to the first occurrence of foo.
I'll have to remember that. Cheers.
I don't really agree about "esc". "Normal mode" is the normal mode as the name indicates. That's where you normally start from. It's the actual writing that's two characters more (start insert mode, write, exit). Unless you're just writing new file from scratch in one go, you're likely to be in normal mode a lot of the time.
Also, shift is not needed for the beginning of the file. It's also "gg" for the first line / "G" for the last.
Regarding the ctrl+home/end, I much prefer not using them. Simply because I switch between 4 different keyboards during the week and I don't know where home/end are without looking. (3 of them being laptops with wildly different layouts) gg/G are on the home row. That's much easier.
Also, shift is not needed for the beginning of the file. It's also "gg" for the first line / "G" for the last.
Regarding the ctrl+home/end, I much prefer not using them. Simply because I switch between 4 different keyboards during the week and I don't know where home/end are without looking. (3 of them being laptops with wildly different layouts) gg/G are on the home row. That's much easier.
"It's the actual writing that's two characters more (start insert mode, write, exit)." Makes sense. Asking for permission to type in a text editor feels counter-intuitive, but I'll give that a try.
Vim really is an editor: It's designed around changing existing text. Inserting new text is just one of the actions you can perform, and you can combine that action with other modifiers, like "5ifoo<esc>" results in foofoofoofoofoo -- 5 repetitions of "insert foo"
This goes better when you know (and have internalized) more of the paths into insert mode.
For instance, ci} will delete everything inside the tightest enclosing braces and switch you to insert mode. This whole thing, then, including what you type, is a single action that you can redo with .
For instance, ci} will delete everything inside the tightest enclosing braces and switch you to insert mode. This whole thing, then, including what you type, is a single action that you can redo with .
What's ^Home / ^End? If it's moving to the beginning / end of a line there are vi shortcuts for that: ^ and $.
I think you're using the editor's modality wrong.
ESC is not used to exit from Insert mode. ESC is used to switch from any mode back to Command mode. In fact Command mode is also called Normal mode. You should spend 95% of your time in Normal mode and use the other modes when you need them.
I suggest binding `kj` to ESC since it allows you to quickly make a change and continue browsing your code. Take the following session:
* Browse and spot something that needs to be changed
* Type `ci(messages, callbackkj`
* Keep browsing with `hjkl` as you're in Normal mode
While it may seem weird, I've yet to find an occurrence of `kj` in a program in years of using this binding and my hands haven't left the keyboard. The cognitive weight is zero as well (at least after building muscle memory).
Now, I believe it depends on the kind of programmers you are. My coworker is the kind who types in a lot of code and rewrites a lot of stuff. I'm the kind of rewires things and make subtle changes after spending a lot of time reading it. In other words it works well for me but probably wouldn't for him.
ESC is not used to exit from Insert mode. ESC is used to switch from any mode back to Command mode. In fact Command mode is also called Normal mode. You should spend 95% of your time in Normal mode and use the other modes when you need them.
I suggest binding `kj` to ESC since it allows you to quickly make a change and continue browsing your code. Take the following session:
* Browse and spot something that needs to be changed
* Type `ci(messages, callbackkj`
* Keep browsing with `hjkl` as you're in Normal mode
While it may seem weird, I've yet to find an occurrence of `kj` in a program in years of using this binding and my hands haven't left the keyboard. The cognitive weight is zero as well (at least after building muscle memory).
Now, I believe it depends on the kind of programmers you are. My coworker is the kind who types in a lot of code and rewrites a lot of stuff. I'm the kind of rewires things and make subtle changes after spending a lot of time reading it. In other words it works well for me but probably wouldn't for him.
If I may use you as a random Vim power user, how do you quickly switch between project files?
Now, I believe it depends on the kind of programmers you are. My coworker is the kind who types in a lot of code and rewrites a lot of stuff. I'm the kind of rewires things and make subtle changes
Interesting, I was thinking something similar - suitability for maintenance vs from scratch.
Interesting, I was thinking something similar - suitability for maintenance vs from scratch.
I use 'jj' rather than 'kj' and except for a pause after I type the first letter of 'join', it works well.
Interesting coincidence, I was pasting a production certificate into Vim the other day and it contained "kj", which escaped the editor and ate a few letters until it reached an "i" and continued pasting.
It took production down for 30 minutes until I noticed it. Remember, kids! ":set paste".
It took production down for 30 minutes until I noticed it. Remember, kids! ":set paste".
[deleted]
> Remember, kids! ":set paste".
Or get used to ctrl-[ which is easier to type than Esc, doesn't skip events(like ctrl-c), and doesn't interfere with anything.
Or get used to ctrl-[ which is easier to type than Esc, doesn't skip events(like ctrl-c), and doesn't interfere with anything.
I usually use `paste` but I sometimes catch myself formatting just-pasted chunks of code. I'll watch out for this.
"+p will paste the system clipboard.
Nah. I've had terrible and inconsistent results with this. I literally hate this thing so much that I've stopped using it altogether. It's most likely due to me not figuring out exactly what's going on but I can't be helped at this point.
No way!
I just tried it, it doesn't work :( That's too bad.
I just tried it, it doesn't work :( That's too bad.
That's for GUI Vim. If you're using Terminal VIM you can install this plugin: https://github.com/kana/vim-fakeclip
Are you on a mac and using the system default vim? If so, Apple cripples it to not be able to directly access the system clipboard -- use homebrew's vim or macvim instead.
No, I'm on Ubuntu, it just looks like this method doesn't work with terminal vim. Your sibling comment looks like it has a solution, though!
I am not sure which version of vim you are on. I have been using clibpoard paste for a long time in Ubunut. Do a ":version" in vim and check if it's compiled with +clipboard. If it is, then it should work.
Also, you can have this in your vimrc:
Also, you can have this in your vimrc:
set clipboard=unnamedplus
Haven't written many blackjack games?
I disagree with this. You're not normally in insert mode when using vim, you're in normal mode (the one vim starts in).
This means that it really is / for searching, 1G to go to the top of the file, w to go one word forward, f( to go to the next opening paren, and ci" to change everything inside the current "..." etc.
What this also means is that when inserting text you start by pressing i, type the text you want to insert and then immediately press ESC (or CTRL+[) to go back to normal mode.
The reason is that everything that is not directly inserting text is much quicker and faster to do in normal mode compared to insert mode once you learn a few of the commands.
I probably only spend a few percent of my vim-time in insert mode, most of it is spent in normal mode.
This means that it really is / for searching, 1G to go to the top of the file, w to go one word forward, f( to go to the next opening paren, and ci" to change everything inside the current "..." etc.
What this also means is that when inserting text you start by pressing i, type the text you want to insert and then immediately press ESC (or CTRL+[) to go back to normal mode.
The reason is that everything that is not directly inserting text is much quicker and faster to do in normal mode compared to insert mode once you learn a few of the commands.
I probably only spend a few percent of my vim-time in insert mode, most of it is spent in normal mode.
> Same with "1G to go to the top of the file, G to go to the bottom" - esc-1-shift-g vs ctrl-home. Same with ctrl-end.
gg beats both (I don't think I've ever used 1G to jump to the top of the file)
gg beats both (I don't think I've ever used 1G to jump to the top of the file)
I was taught that one by the brother-in-law. He also tried to teach me 1234l (the letter 'l') to go to the end of a line. I figured out a better way pretty quickly on that one.
I didn't find the magical 'g' until much later, and 1G was already burned into my synapses. I'm trying to change. It's a little awkward :)
I didn't find the magical 'g' until much later, and 1G was already burned into my synapses. I'm trying to change. It's a little awkward :)
That's actually kind of an interesting idea. $ for end-of-line always bugs me; for something so common I don't think it should require a chord. '999l' is pretty easy to tap out.
On the other hand, it would probably be easier to rebind something like '-' as end-of-line. I'd do backspace, but I've already changed that to PageUp (backspace/space work great as PageUp/PageDown)
On the other hand, it would probably be easier to rebind something like '-' as end-of-line. I'd do backspace, but I've already changed that to PageUp (backspace/space work great as PageUp/PageDown)
Is it common? It's really rare that I need to go to the end of the line and not switch to insert mode. If I do want to go to the end of the line and switch to insert mode, then what I want is A not $. Of course, there's a chord either way, but I'm surprised if you're finding it easier to type 999l than A.
Oh, no - I use A all the time. My use case is generally more v$ followed by some other movement backwards then c,d or y, or Ctrl-V $ and move upwards/downwards.
Ah, 'k, yeah, I don't do visual selection much.
I've been using vim for 5 years and a student showed me you can do it with commands too.
:10 :25 :1
I tend to use that a lot now and I don't know why. However, you can do some pretty cool command with ranges of lines.
:10 :25 :1
I tend to use that a lot now and I don't know why. However, you can do some pretty cool command with ranges of lines.
Why is Esc-/ easier than Ctrl-f (or Ctrl-s in Emacs)?
Esc requires you twist your entire left hand sideways up to hit the Esc, whereas Ctrl requires you move only your left pinky to hit the Ctrl.
Ctrl is more efficient.
Esc requires you twist your entire left hand sideways up to hit the Esc, whereas Ctrl requires you move only your left pinky to hit the Ctrl.
Ctrl is more efficient.
Efficiency really depends upon the keyboard you're using. If you use a keyboard with thumb clusters, the control and meta keys are under your thumbs and you don't need to twist your pinkies at all.
[deleted]
No need to use 1G at all, gg does the same and is one key less.
I don't really understand the comment about etags; if you use ctags in Vim, you'll get the same kind of functionality. If you want something more advanced, Emacs has support for cscope and GNU Global which give you more features. Considering that he's interested in having something better than VimScript and wants org-mode, it seems that Emacs + Evil would really be the best fit for him.
I've never had any problems with etags, either. I've always gotten the same functionality as vim. Maybe we are missing something.
I had this same problem: they function differently in evil mode than Emacs mode; for some reason evil does its own word boundary definitions for etags lookups, and it breaks up words on underscores. I dug into it, and it was some problem with evil's word semantics (that only existed for etags lookups). I ran out of energy to debug it further, and just went back to Vim.
Regular etags called with the emacs bindings worked just fine, but switching contexts from evil mode was a pain.
Regular etags called with the emacs bindings worked just fine, but switching contexts from evil mode was a pain.
Could you mention this on the mailing list? I don't know if I'll have time to fix it any time soon, but someone else might, and that needs to be fixed.
Thanks for quantifying it for me. I never dug in deep enough to figure it out. It always just felt "wonky" when I used. (That's an opinion, of course.)
One feature he missed is its not as configurable, and in some situations that is awesome.
So you're doing something weird, manually, but I repeat myself because if it was BAU you'd automate the whole process in puppet or similar. The local vim will work more or less like every other vim out there. Can't really say that with emacs.
If you're traveling somewhere weird, vim is a great travel companion. Not because it can be compiled anywhere (lots of editors can be compiled anywhere) but because it works the same anywhere.
So you're doing something weird, manually, but I repeat myself because if it was BAU you'd automate the whole process in puppet or similar. The local vim will work more or less like every other vim out there. Can't really say that with emacs.
If you're traveling somewhere weird, vim is a great travel companion. Not because it can be compiled anywhere (lots of editors can be compiled anywhere) but because it works the same anywhere.
I think Vim is potentially as configurable as Emacs, but it is harder to do after you get past some basic key mappings and a few plugins.
In all my exploring of Emacs, I never saw a .emacs that wasn't completely tricked out with custom stuff that only works for that user.
Because of this, I believe you are correct - it's easier to work in a plain vi environment since we don't typically trick out Vim like our fellow Emacs users do with their environment.
In all my exploring of Emacs, I never saw a .emacs that wasn't completely tricked out with custom stuff that only works for that user.
Because of this, I believe you are correct - it's easier to work in a plain vi environment since we don't typically trick out Vim like our fellow Emacs users do with their environment.
Funnily enough, I'm going to other way: long time Emacs users, getting closer to switching to evil-mode (Vi emulation in Emacs). Doubt I'll ever leave Emacs though.
As an aside, how does one keep up with Emacs package development? There is lots of stuff that's new to me (e.g. I just found out about company-mode). I'd like to have some way to have this information pushed to me, rather than having to go searching.
As an aside, how does one keep up with Emacs package development? There is lots of stuff that's new to me (e.g. I just found out about company-mode). I'd like to have some way to have this information pushed to me, rather than having to go searching.
You may want to check r/emacs on reddit. People discuss about new packages there. If someone knows other resources, please let me know as well.
evil-mode is actually pretty good. I've been using it for clojure (paredit is quite nice). Keep in mind, though, that not all packages are gonna work as expected (I had problems with multiple-cursors, for example).
Something I would really recommend you: there are a lot of people in vim (like me) that have remaped the ESC key to a combination of keys (in my case jk); that is, by pressing j followed by k you go to normal mode (it's actually way faster than having to reach ESC). In vim, such thing is very easy; in emacs, you need to install the key-chord package, and something like the following would work:
(require 'key-chord) (key-chord-mode 1) (key-chord-define evil-insert-state-map "jk" 'evil-normal-state) (setq key-chord-two-keys-delay 1.0)
Relative numbers are very nice, as well.
By the way, regarding company-mode, I think autocomplete is newer and it's what most people are using nowadays.
I found out about a bunch of plugins through emacs live and prelude (and then switched to my own config). Take a look to other people's config on github :)
Something I would really recommend you: there are a lot of people in vim (like me) that have remaped the ESC key to a combination of keys (in my case jk); that is, by pressing j followed by k you go to normal mode (it's actually way faster than having to reach ESC). In vim, such thing is very easy; in emacs, you need to install the key-chord package, and something like the following would work:
(require 'key-chord) (key-chord-mode 1) (key-chord-define evil-insert-state-map "jk" 'evil-normal-state) (setq key-chord-two-keys-delay 1.0)
Relative numbers are very nice, as well.
By the way, regarding company-mode, I think autocomplete is newer and it's what most people are using nowadays.
I found out about a bunch of plugins through emacs live and prelude (and then switched to my own config). Take a look to other people's config on github :)
Well, there's a myriad of blog posts about great packages for Emacs, so that covers everything pre-existing.
Add MELPA to your package sources, then just M-x list-packages here and there and check out anything new that looks cool.
Add MELPA to your package sources, then just M-x list-packages here and there and check out anything new that looks cool.
Even now that I'm practically married to SublimeText, I can't stop using classic mode and I still sometimes end up in vim by force of habit.
First you'll learn how to orientate around text quickly using normal mode, then you'll start playing with tabs, splits and buffers to search between multiple files, and then you'll start using registers to save phrases and regular expressions to search directories. At that point you'll never want to leave Vim again.
:wq
:wq
> then you'll start playing with tabs, splits and buffers
I want to like vim's window management but it's pretty quirky, at times it seems to be following the principle of most surprise.
Ideally one could use tabs (that aren't renamed to the buffer name when populating a named tab), splits, and buffers together in such a way that one's layout never, for example, collapses, leaving a single displayed buffer and N hidden ones, or a buffer getting cloned across 2 splits (the latter is pretty disorienting, unless I'm diff'ing versions of a file I don't ever want to see 2 versions of the code consuming visible screen area).
Granted am only 3 days into the vim WM experiment here, lot's to learn...
I want to like vim's window management but it's pretty quirky, at times it seems to be following the principle of most surprise.
Ideally one could use tabs (that aren't renamed to the buffer name when populating a named tab), splits, and buffers together in such a way that one's layout never, for example, collapses, leaving a single displayed buffer and N hidden ones, or a buffer getting cloned across 2 splits (the latter is pretty disorienting, unless I'm diff'ing versions of a file I don't ever want to see 2 versions of the code consuming visible screen area).
Granted am only 3 days into the vim WM experiment here, lot's to learn...
Multiple files is exactly where Vim falls short to me. Sublime and Emacs do that much better, while in Vim it never feels natural. It seems the Vi-way is to exit, and start a new one from the terminal (which is slow for most projects but great for editing /etc/hosts).
:x
(It's the same as :wq, but one character shorter.)
(It's the same as :wq, but one character shorter.)
Even shorter:
ZZ
Colon? That sounds painful, map it to some single keystroke. I use back slash on my tiny cherry keyboard.
noremap \ :Isn't backslash the default <leader> keystroke?
yep, have leader mapped to space ;-)
No it is not the same. x only writes if not already written.
I know this is a minor point but using 'gg' to move to the first line is easier than '1G'.
The author started in vi, which has no gig as far as I can tell.
And I use :0, which is consistent with :N to get to the Nth line, which I also use. (I know, :1 same, just my habit.) And I could use :% to get to the last line, for more consistency, but G is my habit there.
Many ways to edit a cat.
Many ways to edit a cat.
I went back to Sublime after using Vim for a while but then realized I was going to have a terminal open 24/7 anyway so what's the point? Then I learned how to use a terminal multiplexer and now Sublime and other GUI editors just hinder my workflow. IMHO if you're a programmer you should know how to use a terminal to the point that you prefer it over most GUIs (of course, you should always use whatever has the feature you need).
Oh, and on a side note:
Vim and terminal usage is not a "time sink" and it pains me whenever I hear people who consider them selves "programmers" claim it to be. If you haven't learned how to use the terminal yet (or haven't found a use for it) then you aren't a respectable programmer IMHO. I would not read a book on programming by someone who doesn't know how to use a terminal and I would not take a class on programming taught by a professor who doesn't know how to use a terminal.
Oh, and on a side note:
Vim and terminal usage is not a "time sink" and it pains me whenever I hear people who consider them selves "programmers" claim it to be. If you haven't learned how to use the terminal yet (or haven't found a use for it) then you aren't a respectable programmer IMHO. I would not read a book on programming by someone who doesn't know how to use a terminal and I would not take a class on programming taught by a professor who doesn't know how to use a terminal.
In my opinion, other people's opinions about how I program are worth just about nothing.
I'll never understand the sort of arrogance that leads to posting things like that. do you really believe you're so smart that you figured out the only way anyone should do anything?
I'll never understand the sort of arrogance that leads to posting things like that. do you really believe you're so smart that you figured out the only way anyone should do anything?
Well, I wasn't trying to be arrogant.. sorry. But would you really take a programming class taught by a professor who doesn't know how to use a terminal?
Fondness for the terminal or shell is a question of mindset, not ability. You might be surprised (as I was... and, if I'm honest, still am, a little) at how many skilled programmers there are who don't know how to use it, and how many of those that do know, don't actually make use of that knowledge. And yet, they are still worth paying attention to, unless perhaps you're wanting advice about shell commands.
And on the flip side I have also met a number of (relative) dullards whose shell skills were unquestionable.
And on the flip side I have also met a number of (relative) dullards whose shell skills were unquestionable.
Well, Alan Turing certainly did not know how to use a terminal :) For some reason his work is still highly relevant today. So yes, I would.
What is there to learn about the terminal? You learn the shell, coreutils, shell scripting, sed, awk, editor...Learning these isn't a measure of competency. If you just want name dropping, John Carmack works in Visual Studio, Notch works in Eclipse.
Yes, absolutely. It'd be a little odd if they hadn't picked up that skill, but I don't see what relevance using or preferring vim could have to, say, teaching functional programming.
Knowing how to use a terminal != using a terminal for everything.
[deleted]
I never said that. Anywhere.
Yet you seem to be mixing these things up.
> IMHO if you're a programmer you should know how to use a terminal to the point that you prefer it over most GUIs
Knowing how to use a terminal: Yes, should be required and isn't taught enough. Preferring it for almost any task - no, it depends on the task and it depends on what you're the most efficient with. I have yet to see a clinical study showing that terminal editing leads to performance improvements over proficient use of hotkey based editing with keyboard and mouse. I have nothing against people using it on a project I lead, but I would never make it a criterium.
> Vim and terminal usage is not a "time sink" and it pains me whenever I hear people who consider them selves "programmers" claim it to be.
Again, you're mixing up terminal proficiency with using it as a your main editor, then belittle those who don't agree with you.
> If you haven't learned how to use the terminal yet (or haven't found a use for it) then you aren't a respectable programmer IMHO.
I agree with that, but it's a different point as outlined above.
> IMHO if you're a programmer you should know how to use a terminal to the point that you prefer it over most GUIs
Knowing how to use a terminal: Yes, should be required and isn't taught enough. Preferring it for almost any task - no, it depends on the task and it depends on what you're the most efficient with. I have yet to see a clinical study showing that terminal editing leads to performance improvements over proficient use of hotkey based editing with keyboard and mouse. I have nothing against people using it on a project I lead, but I would never make it a criterium.
> Vim and terminal usage is not a "time sink" and it pains me whenever I hear people who consider them selves "programmers" claim it to be.
Again, you're mixing up terminal proficiency with using it as a your main editor, then belittle those who don't agree with you.
> If you haven't learned how to use the terminal yet (or haven't found a use for it) then you aren't a respectable programmer IMHO.
I agree with that, but it's a different point as outlined above.
[deleted]
You seem to be making the assumption that knowing how to use the terminal is equivalent to preferring to do everything in it. What about people that know how to use the terminal, but prefer to use a GUI text editor like Sublime?
This might surprise you, but the vast majority of developers manage to get by without learning how to use a terminal. They really do. Saying you wouldn't listen to a developer that doesn't use a terminal is just silly - do you know just how many things there are to learn in the world of programming? Everyone has something they've never learned.
Also - can I just ask, as someone who "uses a terminal" but doesn't really get why people talk about it like it's so amazing - what am I doing wrong? What do you use a terminal for that makes it so important?
Also - can I just ask, as someone who "uses a terminal" but doesn't really get why people talk about it like it's so amazing - what am I doing wrong? What do you use a terminal for that makes it so important?
It's not the terminal, it's the shell.
The terminal is a relatively standardized display with some severe limitations and kludgyness. The DOM of its era.
The shell, which happens to typically live in the terminal, has three things going for it that GUI interfaces frequently lack.
First, composability and automation: any action you can fire off from the shell, you can fire off from a shell script. Any data you're given by a utility, you can operate on and send to any other utility. Any data you're asked to provide can come from anywhere.
Second, narrative structure with history and a sense of place. "I did X, then I did Y, so now I need to Z... wait, what did X say?" is a natural mode of interaction convenient to many sorts of tasks.
Third, extensibility. Write any new utility (whether in the shell or in any language other you choose) and it is quickly a first class piece of your toolset. (This is the most common of the three to find in GUI land, though it often has limitations).
The terminal is a relatively standardized display with some severe limitations and kludgyness. The DOM of its era.
The shell, which happens to typically live in the terminal, has three things going for it that GUI interfaces frequently lack.
First, composability and automation: any action you can fire off from the shell, you can fire off from a shell script. Any data you're given by a utility, you can operate on and send to any other utility. Any data you're asked to provide can come from anywhere.
Second, narrative structure with history and a sense of place. "I did X, then I did Y, so now I need to Z... wait, what did X say?" is a natural mode of interaction convenient to many sorts of tasks.
Third, extensibility. Write any new utility (whether in the shell or in any language other you choose) and it is quickly a first class piece of your toolset. (This is the most common of the three to find in GUI land, though it often has limitations).
>but the vast majority of developers manage to get by without learning how to use a terminal.
But not the good ones. Would you take a college class on programming from a professor who doesn't know how to use a terminal? I wouldn't.
But not the good ones. Would you take a college class on programming from a professor who doesn't know how to use a terminal? I wouldn't.
> If you haven't learned how to use the terminal yet (or haven't found a use for it) then you aren't a respectable programmer IMHO.
If you are mocking people and their mothers on HN[1], you aren't a respectful person. Within this entire thread, you are being disrespectful, arrogant, and insulting. This isn't what HN is about.
Correct your tone or leave.
[1] https://news.ycombinator.com/item?id=7961305
If you are mocking people and their mothers on HN[1], you aren't a respectful person. Within this entire thread, you are being disrespectful, arrogant, and insulting. This isn't what HN is about.
Correct your tone or leave.
[1] https://news.ycombinator.com/item?id=7961305
> Correct your tone or leave.
It's true that the comment you linked to was way out of line, but if you're going to ask other users to be civil, please be civil yourself. It takes restraint, but it's necessary.
It's true that the comment you linked to was way out of line, but if you're going to ask other users to be civil, please be civil yourself. It takes restraint, but it's necessary.
You've reiterated your point about terminal knowledge being the mark of a programmer, but you've not really outlined the reason for it. I'm sympathetic to the view that a programmer should know her tools, but this discussion has mostly become name-calling (on both sides).
I do all of my programming work in one terminal or another and I still disagree with you. Programming isn't about typing text.
I'm not a seasoned user or anything, but I prefer to use Emacs with a GUI rather than in the terminal. It has nothing do with there being more GUI-type things in there - I have things like save-icons etc. turned off. It just feels more like it's own application in GUI mode (if I run it in terminal mode, the Meta hotkey doesn't work as usual, which I suspect is because the terminal is using the alt-key (meta) for something else and so it overrides that hotkey). Why should I prefer to use Emacs in terminal mode? I am honestly open to changing my mind.
The only advantage I know for using emacs in terminal is that you can get used to it when you'll have to ssh into a remote server.
Anyway today we can just sshfs and use even a random ide for everything so... we can do as we like.
Anyway today we can just sshfs and use even a random ide for everything so... we can do as we like.
In my experience, any sort of filesystem remoting a la sshfs simply doesn't perform well enough to do real editing work in. One of the really nice things about vi is that it was originally designed for low-bandwidth situations, so using it over ssh is quite snappy even on a marginal network. If I had to use sshfs from home to edit files on my production servers I would probably have to kill myself.
I agree. I can comfortably get seconds ahead of what's displayed on my phone, when needing to fix something in an area of poor coverage. Knowing my ASCII chart can come in handy, on the limited phone keyboard, though...
Running in a terminal means you can run it in screen/tmux, which has a few upsides, though they may not be relevant to your workflow.
Another potential advantage to running from a terminal is that you inherit shell variables that can be used in the editor or in utilities run from the shell. Of course, you can set these for GUI-mode emacs (or vim), but I've found terminal windows and screen a good way of isolating contexts and making sure things are set up appropriately.
"Anyone who doesn't have the same exact opinion as me isn't a real programmer."
Is that correct?
Is that correct?
If you join my team and tell me you're a programmer but when you sit down with a terminal you have no idea what to do, then you're off my team and I don't respect you as a programmer.
Sorry if this offends you, but how can you consider your self a programmer when you don't know how to use a terminal?
Sorry if this offends you, but how can you consider your self a programmer when you don't know how to use a terminal?
So Windows programmers, according to you aren't programmers?
I'd consider someone a programmer if they can program. Whatever their preferred workflow is, is completely irrelevant if they can deliver.
Why would I sit down with a terminal when I don't need a terminal to do the type of programming that I do?
Furthermore, anyone who knows how to type and read knows how to use a terminal - it's really not that special of a skill mate :)
Furthermore, anyone who knows how to type and read knows how to use a terminal - it's really not that special of a skill mate :)
What programming do you do? css?
I do C# in Visual Studio all day long. Rarely (if ever) need to touch the terminal. Hundreds of thousands of people use my apps. But nope - I guess I'm not a real programmer because "I don't prefer the terminal". Give us a break mate. Nobody agrees with you.
WorldWideWayne thanks for opening my eyes. You sure are smart. :^)
edit: I just had to post this from your comment history, I think we could both use a chuckle:
"I'm the other VIC-20 vote so far and I don't know where my family had gotten that computer. It came with a book of BASIC programs that you could type in but we didn't have have a storage unit (tape drive), so each time I wanted to play a game I had to type the entire program in and run it. Most of the time I asked my mom to type it in for me, but I remember a couple of times that I spent the hour hunting and pecking in order to play my favorite game (Moon Rover or something, I forget the name)."
You still getting mom to type in terminal commands for you?
edit: I just had to post this from your comment history, I think we could both use a chuckle:
"I'm the other VIC-20 vote so far and I don't know where my family had gotten that computer. It came with a book of BASIC programs that you could type in but we didn't have have a storage unit (tape drive), so each time I wanted to play a game I had to type the entire program in and run it. Most of the time I asked my mom to type it in for me, but I remember a couple of times that I spent the hour hunting and pecking in order to play my favorite game (Moon Rover or something, I forget the name)."
You still getting mom to type in terminal commands for you?
What I never heard explained in one sentence about vi is: why have multiple modes? Why not zero modes instead?
Multiple modes allows the same keys to do different things in different modes, there isn't much more to it than that.
Say, at a Bash shell prompt in a terminal window, pressing Ctrl+R starts "reverse command search" mode, so that pressing letter keys searches for commands entered in the past, rather than entering a new command. In this mode, up and down move through search results, rather than moving through the entire command history like in "normal" mode.
Lots of software has modes, the unusual thing about Vim is that they have names, and that there is a mode with a focus on navigation.
Say, at a Bash shell prompt in a terminal window, pressing Ctrl+R starts "reverse command search" mode, so that pressing letter keys searches for commands entered in the past, rather than entering a new command. In this mode, up and down move through search results, rather than moving through the entire command history like in "normal" mode.
Lots of software has modes, the unusual thing about Vim is that they have names, and that there is a mode with a focus on navigation.
Why have a mode focused on navigation? Is there something this mode allows beyond navigating? What would be impossible to do if you didn't have this mode?
The keyboard allows you to navigate too, without the need for a mode.
The keyboard allows you to navigate too, without the need for a mode.
Keep in mind that a lot of the keyboard features we take for granted weren't always present on early terminals. Navigating is a lot harder if you don't have, say, arrow keys. In that case, a separate mode makes a lot of sense for getting around (no arrow keys? Just map hjkl to them in navigation mode). Plus the same command can do different things depending on mode, so there are less distinct patterns of keypresses to memorize. Yes, you could do everything as a series of chords (like in emacs), but I don't think it's necessarily superior.
Here's a list of some navigation mode commands. You can probably come up with reasonable ways to do them with only the keyboard & none of the alphanumeric or punctuation keys used alone, but would that be any easier? http://www.thegeekstuff.com/2009/03/8-essential-vim-editor-n...
Here's a list of some navigation mode commands. You can probably come up with reasonable ways to do them with only the keyboard & none of the alphanumeric or punctuation keys used alone, but would that be any easier? http://www.thegeekstuff.com/2009/03/8-essential-vim-editor-n...
It's used for text manipulation, too - the advantage lies in the fact that the same navigation keys are used to operate on blocks of text. For example, move to the next close-parenthesis can become copy everything up to next close-parenthesis, move to the next blank line can become indent everything up until the next blank line, move to the end of the line can become delete everything up to the end of the line, etc.
(For the record - I think it was a legitimate question. Upvoted!)
(For the record - I think it was a legitimate question. Upvoted!)
I interpret it as a positive sign when someone downvotes without an explanation (live above). It's a sign they don't understand a topic well enough to refute its main point. I'm sorry if the comment above also caused you to grow indignant.
A better response would have been to zoom in at the main argument and say the most important thing there is about it.
If you aren't downvoted enough you are probably not revealing anything controversial.
A better response would have been to zoom in at the main argument and say the most important thing there is about it.
If you aren't downvoted enough you are probably not revealing anything controversial.
Please don't post about being downvoted on HN. As the site guidelines say, it never helps and makes for boring reading.
Downvoting happens to everybody, and most unfair downvotes are corrected after a while by other users, rendering the complaint even more pointless.
Downvoting happens to everybody, and most unfair downvotes are corrected after a while by other users, rendering the complaint even more pointless.
it never helps
I'm not sure how true that is and I might be able to prove it.
(1) One way it could help is: if I could get feedback about where I went astray. That's what I want to know when I'm downvoted. I don't care about a karma point, I care about learning something new.
Which makes me wonder: would it help to ask people explain why they downvoted something -- even if their username doesn't get attached to an explanation that becomes public?
(2) Here's an instance where it actually helped: [1]. Me explaining in [2] why [1] was downvoted (which was at something like -1 at the time) lead into [1] being voted again and [2] being upvoted too for clarifying the situation.
(3) This comment is aligned with HN's own request for providing feedback about what's good and bad for HN comments [3].
(4) You should be alarmed when you see a guilty word like "never" used. Particularly if you are the one using it. It's an alarm that indicates you are going to an extreme to justify a position. If what you say is evidently true, you wouldn't feel the need to try hard to qualify it. Or at least, when I made this argument in [4] people voted 20 points for it (which you dang can verify as an administrator).
(5) These arguments suggest reviewing the site guidelines and it's hard to dismiss them as useless. They could improve HN.
[1] - https://news.ycombinator.com/item?id=7285865
[2] - https://news.ycombinator.com/item?id=7288741
[3] - https://news.ycombinator.com/item?id=7605973
[4] - https://news.ycombinator.com/item?id=7565441
I fully understand if what you've discovered studying downvotes is that dealing with them differently leads into more problems than it does dealing with them with the advice of "don't post about being downvoted". I also understand if you are not willing to deal with those problems now. But saying "it never helps" sounds far fetched. You are claiming there's nothing that can be done about downvotes, ever. That's a strong claim to make, especially in a field that's only 50 years old.
I'm not sure how true that is and I might be able to prove it.
(1) One way it could help is: if I could get feedback about where I went astray. That's what I want to know when I'm downvoted. I don't care about a karma point, I care about learning something new.
Which makes me wonder: would it help to ask people explain why they downvoted something -- even if their username doesn't get attached to an explanation that becomes public?
(2) Here's an instance where it actually helped: [1]. Me explaining in [2] why [1] was downvoted (which was at something like -1 at the time) lead into [1] being voted again and [2] being upvoted too for clarifying the situation.
(3) This comment is aligned with HN's own request for providing feedback about what's good and bad for HN comments [3].
(4) You should be alarmed when you see a guilty word like "never" used. Particularly if you are the one using it. It's an alarm that indicates you are going to an extreme to justify a position. If what you say is evidently true, you wouldn't feel the need to try hard to qualify it. Or at least, when I made this argument in [4] people voted 20 points for it (which you dang can verify as an administrator).
(5) These arguments suggest reviewing the site guidelines and it's hard to dismiss them as useless. They could improve HN.
[1] - https://news.ycombinator.com/item?id=7285865
[2] - https://news.ycombinator.com/item?id=7288741
[3] - https://news.ycombinator.com/item?id=7605973
[4] - https://news.ycombinator.com/item?id=7565441
I fully understand if what you've discovered studying downvotes is that dealing with them differently leads into more problems than it does dealing with them with the advice of "don't post about being downvoted". I also understand if you are not willing to deal with those problems now. But saying "it never helps" sounds far fetched. You are claiming there's nothing that can be done about downvotes, ever. That's a strong claim to make, especially in a field that's only 50 years old.
Its reason for existence is historical, but it persists because it is useful.
"Normal mode" (the most common mode other than insert mode) uses key bindings that wouldn't be possible in insert mode, rather than using the ctrl/alt/etc. keys for binding. For example, hovering over a word and typing ciw (change-in-word) will delete the word and place you in insert mode. There is a nice grammar and logic to the default key bindings (mostly.)
(IMO) When you are experienced with Vim you will spend most of your time in normal mode. This has a few benefits. For one, undo in Vim is "transactional" as you enter and leave insert mode (its a little more complicated but nevermind.) Everytime I have to use other editors (like VS with the VSVim extension) it drives me batty when I have to undo/redo one-character-at-a-time or with some time based batching that I don't understand. (Plug: the GUndo.vim plugin gives you a usable interface to Vim's undo tree. It's not super common for me to need this, but when I do it is a godsend. (If you've ever done undo, made some edits, and wish you hadn't undone after all, this is for you.)
"Normal mode" (the most common mode other than insert mode) uses key bindings that wouldn't be possible in insert mode, rather than using the ctrl/alt/etc. keys for binding. For example, hovering over a word and typing ciw (change-in-word) will delete the word and place you in insert mode. There is a nice grammar and logic to the default key bindings (mostly.)
(IMO) When you are experienced with Vim you will spend most of your time in normal mode. This has a few benefits. For one, undo in Vim is "transactional" as you enter and leave insert mode (its a little more complicated but nevermind.) Everytime I have to use other editors (like VS with the VSVim extension) it drives me batty when I have to undo/redo one-character-at-a-time or with some time based batching that I don't understand. (Plug: the GUndo.vim plugin gives you a usable interface to Vim's undo tree. It's not super common for me to need this, but when I do it is a godsend. (If you've ever done undo, made some edits, and wish you hadn't undone after all, this is for you.)
Efficiency trumps tradition in this istance. The reason for horse carriages is historical too and persists because it is useful but a horse carriage isn't as efficient as a car.
One measure of effectiveness would be: to count the number of keystrokes needed to do something in vi compared to other editors.
One measure of effectiveness would be: to count the number of keystrokes needed to do something in vi compared to other editors.
What I have found is that ALL editors have modes. Most default to edit mode, and require key sequences to invoke other commands (Ctrl, Alt, Shift, Function keys, Menu choices, etc), then drop you back into edit mode.
Vi chose _a_ way of working. Turns out, a lot of folks have taken to it over the years. (And a lot haven't. They're nice people, too) :)
EDIT: fixed a typo
Vi chose _a_ way of working. Turns out, a lot of folks have taken to it over the years. (And a lot haven't. They're nice people, too) :)
EDIT: fixed a typo
If you have multiple modes you can basically reuse the entire keyboard for commands. That's one advantage that is impossible to achieve in non-modal editors. Ctrl-ing, Alt-ing, Shift-ing stuff just isn't the same, especially as those commands get more and more complex.
Esc-ping isn't the same either. What makes pressing a key (Escape) to enter a mode better than Ctrl, Alt, Shift to enter a mode?
It's also not true that it's impossible to make other editors work like vi. evil-mode in Emacs lets you work like vi.
It's also not true that it's impossible to make other editors work like vi. evil-mode in Emacs lets you work like vi.
You don't press escape to enter a mode, you press escape to leave another mode and return to normal mode.
Most vim users are only in insert mode when... inserting text.
Most vim users are only in insert mode when... inserting text.
We’re surrounded by modes. Your microwave has modes; so does your (digital) watch, MP3 player, your wireless access point, etc.
Having modes in a text editor also makes sense; modes provide affordances to get certain things done.
Having modes in a text editor also makes sense; modes provide affordances to get certain things done.
I like to think of it this way:
Why should I have to hold down a modifier key for 5 minutes? Just make it toggle.
Take that to its logical extension and you get modes, and they are beautiful.
Why should I have to hold down a modifier key for 5 minutes? Just make it toggle.
Take that to its logical extension and you get modes, and they are beautiful.
Because as a programmer your time is dominated by editing rather than creating text, therefore it is more efficient for every key to default to direct access to an editing function.
That's too broad of a stroke on what a programmer does with text. It's not just about editing. It's also about (a) moving to the point where you want to edit, (b) moving to an other point right after you just finished editing. Switching between the two becomes harder when you always have to Escape, compared to having direct access to an arrow key.
And (c) about editing. Why type an extra character (i for insert) to let you insert? Why not just type to insert?
And (c) about editing. Why type an extra character (i for insert) to let you insert? Why not just type to insert?
In modern vim you do have direct access to the arrow keys. Rarely is this meaningful, for someone skilled in vim.
It can potentially be faster if you need to move just a couple characters over, but if you need to move 25? It winds up being something like: Esc 22hhhh
People navigate by jumping across words, across features, searching...
It can potentially be faster if you need to move just a couple characters over, but if you need to move 25? It winds up being something like: Esc 22hhhh
People navigate by jumping across words, across features, searching...
I wonder if there's navigation modern vim doesn't offer. Can you tell if or how you can do the following in vim?
In Emacs, Ctrl-<up arrow> moves the cursor ahead of a block of code. If you had a for loop for example, with a blank line where the for begins and a blank line where it ends, and the cursor was at the blank line where it ends, pressing the two keys Ctrl and <up arrow> would put you in the beginning.
How would you do this in vim? Would you have to first gauge how many lines of text up you should move?
In Emacs, Ctrl-<up arrow> moves the cursor ahead of a block of code. If you had a for loop for example, with a blank line where the for begins and a blank line where it ends, and the cursor was at the blank line where it ends, pressing the two keys Ctrl and <up arrow> would put you in the beginning.
How would you do this in vim? Would you have to first gauge how many lines of text up you should move?
Potentially depends a bit on the language and what plugins &c you have installed. For C on a basic install, you can say [{ to jump to the enclosing { (and there is the symmetric ]} as well). You can also use { and } to step over "paragraphs". And of course, if your goal is to replace the body of the for loop, ci} will delete everything inside the innermost containing {} and switch you to insert mode.
Yes, but unlike every other reply, I actually answered in one sentence didn't I? The fact that my sentence is difficult to grok for someone who is not already familiar with vim is hardly my fault.
But I'll elaborate on your points:
> It's not just about editing. It's also about (a) moving to the point where you want to edit
This is implicitly part of editing. vim offers more ways to move than any other editor, this goes directly to my point. Whereas in most editors you are crippled without a mouse, or at least clumsily moving around with arrow keys plus chords, vim have several movement commands that would not be possible without normal mode because you would just be typing text rather than powerfully moving around your document (eg. (, ), [, ], e, g, f, F, t, T, b, etc). Those examples are in addition to hjkl which are equivalent to arrow keys but of course more powerful because you can add number before them.
> Switching between the two becomes harder when you always have to Escape
No it's not, escape is just what you hit to finish a command. It's no different than hitting return at the end of a paragraph. It becomes reflexive and is far less of a burden over time than the extra key stroke of holding Shift, Ctrl, Alt, or Command keys which is taken for granted by non-vim users as the only way for keyboard commands to exist.
> compared to having direct access to an arrow key.
You can have direct access to arrow keys in vim if you want, but people recommend against it because newbies tend to use them as a crutch to avoid learning better movements. I'm not a purist, and I keep arrows in insert mode, but I map them more powerful things like switching tabs in normal mode.
> Why type an extra character (i for insert) to let you insert? Why not just type to insert?
Because in this one sentence I am typing there are 20 extremely powerful commands that I'm giving up in order to have the convenience of not typing `i` before I write the sentence.
Additionally, what if I want to insert text on a new line (o, O), or if I want to replace some text that is already there (c, C, cw, cW, c, 5cc, ca", ci[, etc)? `i` is not just an extra requirement, it's a choice about what kind of edit I want to make. Furthermore, when I'm done, if I want to insert the same text again I just hit `.`. Gaining fluency in this type of workflow leads to super optimized workflows, like manually find and replacing the word foo with bar:
IDEs can do a better job by building advanced tools for specific languages. Modern editors can do a better job integrating into the OS. Emacs does a better job at customizability. But nothing matches vim's raw editing capability on arbitrary text.
But I'll elaborate on your points:
> It's not just about editing. It's also about (a) moving to the point where you want to edit
This is implicitly part of editing. vim offers more ways to move than any other editor, this goes directly to my point. Whereas in most editors you are crippled without a mouse, or at least clumsily moving around with arrow keys plus chords, vim have several movement commands that would not be possible without normal mode because you would just be typing text rather than powerfully moving around your document (eg. (, ), [, ], e, g, f, F, t, T, b, etc). Those examples are in addition to hjkl which are equivalent to arrow keys but of course more powerful because you can add number before them.
> Switching between the two becomes harder when you always have to Escape
No it's not, escape is just what you hit to finish a command. It's no different than hitting return at the end of a paragraph. It becomes reflexive and is far less of a burden over time than the extra key stroke of holding Shift, Ctrl, Alt, or Command keys which is taken for granted by non-vim users as the only way for keyboard commands to exist.
> compared to having direct access to an arrow key.
You can have direct access to arrow keys in vim if you want, but people recommend against it because newbies tend to use them as a crutch to avoid learning better movements. I'm not a purist, and I keep arrows in insert mode, but I map them more powerful things like switching tabs in normal mode.
> Why type an extra character (i for insert) to let you insert? Why not just type to insert?
Because in this one sentence I am typing there are 20 extremely powerful commands that I'm giving up in order to have the convenience of not typing `i` before I write the sentence.
Additionally, what if I want to insert text on a new line (o, O), or if I want to replace some text that is already there (c, C, cw, cW, c, 5cc, ca", ci[, etc)? `i` is not just an extra requirement, it's a choice about what kind of edit I want to make. Furthermore, when I'm done, if I want to insert the same text again I just hit `.`. Gaining fluency in this type of workflow leads to super optimized workflows, like manually find and replacing the word foo with bar:
/fooc2fobarn.n.n.n.n.n.n.n.n.n.n.n.n.n.n
IDEs can do a better job by building advanced tools for specific languages. Modern editors can do a better job integrating into the OS. Emacs does a better job at customizability. But nothing matches vim's raw editing capability on arbitrary text.
I learned a lot about how a vim user thinks and works from this comment. Thank you for explaining.
>q to record a macro; @ to execute it again
Is using macros' really common? I haven't yet figured out in when and where to use macros during my workflow.
Is using macros' really common? I haven't yet figured out in when and where to use macros during my workflow.
I do a lot of work on multiple rows/sections/blocks of similar data. My workflow usually goes like this...
1. Do the same thing 3 times, realize that I'll be done faster if I automate it. 2. qz to record a macro into buffer z. 3. Do the work, taking care to leave myself in a state where the next invocation of the macro will pick up right where I want it to. 4. q to finish recording. 5. :map <M-f12> @z to execute buffer z 6. Hit Alt-f12 over and over until I'm done.
Seems like a lot of steps, but it has saved me tons of time.
Of course, as the other commenter said, some folks don't use the feature. That's ok. There's room for all kinds :)
1. Do the same thing 3 times, realize that I'll be done faster if I automate it. 2. qz to record a macro into buffer z. 3. Do the work, taking care to leave myself in a state where the next invocation of the macro will pick up right where I want it to. 4. q to finish recording. 5. :map <M-f12> @z to execute buffer z 6. Hit Alt-f12 over and over until I'm done.
Seems like a lot of steps, but it has saved me tons of time.
Of course, as the other commenter said, some folks don't use the feature. That's ok. There's room for all kinds :)
I use Vim on structured, tabular data quite a bit (think CSVs/TSVs/large HTML tables/etc.). Macros are handy for handling complex operations on rows like "skip the first two fields; delete this column; add this new column; make everything in this column uppercase; delete the rest". Just start recording, edit the first row and apply it to every other line when you're finished.
Macros are fabulous! Any time you're going to edit multiple lines in the same way, bam! For instance, you've got a create table script, and want to turn the column defs into some code or type definitions. For me, macros are quicker than getting a regex right.
Or perhaps you're cleaning up a file, and there's a few common changes. Pop each into a macro and go to town. The low friction aspect makes them more common than the name might sound.
Or perhaps you're cleaning up a file, and there's a few common changes. Pop each into a macro and go to town. The low friction aspect makes them more common than the name might sound.
Thank you for asking that.
I have been wondering the same thing for some time. I always hear how great macros are, but haven't actually found a real world use case in my work.
But I figured it was because I didn't know something.
I have been wondering the same thing for some time. I always hear how great macros are, but haven't actually found a real world use case in my work.
But I figured it was because I didn't know something.
Vim user of 18yrs here. I never use macros.
Everyone uses a slightly different subset of vim, in slightly different ways.
Don't worry about dogmas. Try everything out once, and keep what works for you!
Everyone uses a slightly different subset of vim, in slightly different ways.
Don't worry about dogmas. Try everything out once, and keep what works for you!
I use a text editor because using a text editor that you've mastered is pleasant. (I'm an Emacs user fwiw.)
I think we should stop trying to rationalize this choice.
Or rather, we should realize that we like text editors because we went through a long training and acquired complex skills which are fun to put in practice. Being a power user of Emacs or Vim is is satisfying, the same way mastering a video game is satisfying.
I think we should stop trying to rationalize this choice.
Or rather, we should realize that we like text editors because we went through a long training and acquired complex skills which are fun to put in practice. Being a power user of Emacs or Vim is is satisfying, the same way mastering a video game is satisfying.
Exactly. It's why I wrote the article. For me, using Vim brings with it a whole general feeling of comfort, which probably includes those early days hacking away on the Xenix box with family close by and Mario dinging in up the hallway.
Weird, I know. But whenever I come back to Vim after straying for any amount of time, I just feel happy. Probably because I can do everything I want to do in the text without having to think about it.
Weird, I know. But whenever I come back to Vim after straying for any amount of time, I just feel happy. Probably because I can do everything I want to do in the text without having to think about it.
I get the same feeling. It's usually accompanied by the similar feeling I get when I drop back into a linux terminal after having spent eight or nine hours at work on .net. I just sort of automatically relax and feel good, heh.
It's like the nostalgia I get when the seasons change, and for a few days I can feel my childhood.
It's like the nostalgia I get when the seasons change, and for a few days I can feel my childhood.
If that is so, why do people change text editors? (I agree with you, I just wonder this myself)
I'm only speaking for myself with the below. ymmv of course
I get the "grass is greener" feeling sometimes, so I go looking to see if anything better has come along.
Then there's just the practical switch. My main job is in .net right now, while my home computers are all linux distros. It's made me search through a lot of editors to find something that runs well and feels good with windows.
I also just like to explore software, you know? A for instance would be Sublime Text. I've said it in a few other threads, but I do dig some of the features in ST2. They really did multiple cursors right. It's a really simple, but intuitive and powerful way to edit things. Using that on ST2 me want it everywhere else, and also made me fall in love with how they set up the command palette. Using emacs for a bit made me really dig how elisp worked. Light Table showed me another take on the integration of a language into the editor itself. So it's a lot of curiosity with that, and to know what's out there.
As an aside, if Neovim delivers it's promises, it'll probably solidify vim even further as my only editor of choice, but I'll still go looking around to see what other people are coming up with.
I get the "grass is greener" feeling sometimes, so I go looking to see if anything better has come along.
Then there's just the practical switch. My main job is in .net right now, while my home computers are all linux distros. It's made me search through a lot of editors to find something that runs well and feels good with windows.
I also just like to explore software, you know? A for instance would be Sublime Text. I've said it in a few other threads, but I do dig some of the features in ST2. They really did multiple cursors right. It's a really simple, but intuitive and powerful way to edit things. Using that on ST2 me want it everywhere else, and also made me fall in love with how they set up the command palette. Using emacs for a bit made me really dig how elisp worked. Light Table showed me another take on the integration of a language into the editor itself. So it's a lot of curiosity with that, and to know what's out there.
As an aside, if Neovim delivers it's promises, it'll probably solidify vim even further as my only editor of choice, but I'll still go looking around to see what other people are coming up with.
Haven’t installed this yet, but it looks promising for multiple cursor support for Vim: http://vimawesome.com/plugin/vim-multiple-cursors
If the analogy holds, the answer is the same reason people play different video games. I think the analogy holds a bit: variety and different kinds of mastery feel like a correct answer.
Yay, I'm glad J got a shout-out even if it is one of the rejected editors. I've loved using J in the past and have even made a few releases of J on sourceforge [0]. I've attempted to move to github as well [1]. Sadly, I haven't found much time to work on it -- paid work and family take precedence. Oh, and I too love using vim as well.
[0] http://armedbear-j.sourceforge.net/
[1] https://github.com/kevinkrouse/j/tree/master/jI can't stop using vi key bindings, whether that's Evil for Emacs, VsVim for Visual Studio, the Intellij one, Sublime, etc..
But my days of using straight Vim are over. For a straight text editor, I finally got over the hump with Emacs recently, and I'm not going back.
But my days of using straight Vim are over. For a straight text editor, I finally got over the hump with Emacs recently, and I'm not going back.
> and ‘Esc’ to move around again.
For me personally this is the reason I stopped using Vi(m) except for occasional config file editing on unfamiliar servers, and started looking elsewhere (Emacs) for my goto text editor. I'm not looking to switch, but it genuinely interests me how Vi users put up with the constant need to strain their pinky to switch to command mode.
For me personally this is the reason I stopped using Vi(m) except for occasional config file editing on unfamiliar servers, and started looking elsewhere (Emacs) for my goto text editor. I'm not looking to switch, but it genuinely interests me how Vi users put up with the constant need to strain their pinky to switch to command mode.
> it genuinely interests me how Vi users put up with the constant need to strain their pinky to switch to command mode.
Is it any different from how emacs users put up with Ctrl/Alt?
You aren't looking to switch, but if anybody is, install this https://github.com/tpope/vim-rsi for basic keybinding in insert mode. This is quite a short file. If you want, you can simply copy it to your .vimrc. For non-basic movement/editing, switch to normal mode and edit.
Is it any different from how emacs users put up with Ctrl/Alt?
You aren't looking to switch, but if anybody is, install this https://github.com/tpope/vim-rsi for basic keybinding in insert mode. This is quite a short file. If you want, you can simply copy it to your .vimrc. For non-basic movement/editing, switch to normal mode and edit.
You've got a couple of options here - I personally have remapped my Caps Lock key to escape (not many downsides, besides limiting my ability to post humorous trolling messages).
You can also use Ctrl-[ which I believe essentially sends an escape character to whatever program you happen to be running.
Both options should save your pinky!
You can also use Ctrl-[ which I believe essentially sends an escape character to whatever program you happen to be running.
Both options should save your pinky!
Ctrl-[ is the ASCII for Esc. Ctrl effectively subtracts 0x40. So:
Ctrl-A = 0x41 - 0x40 = 0x01 = SOH
Ctrl-I = 0x49 - 0x40 = 0x09 = Tab
Ctrl-M = 0x4D - 0x40 = 0x0D = CR
Ctrl-[ = 0x5B - 0x40 = 0x1B = Esc
Ctrl-@ = 0x40 - 0x40 = 0x00 = NULI've heard of people rebinding it to caps lock. It makes sense as long as you don't mind holding down shift for the occasional all-caps text.
I've learned to love the modal nature of vim, or rather, the notion that text entry ('insert' mode) is merely one aspect of manipulating text. The combination of movement of commands is very powerful and these days I feel naked when I use editors without this ability.
My first dedicated text editor was BBedit (when it was still freeware), and for many years had extended experiments with other editors, always eventually returning to BBEdit. Something about it always clicked with me, and I felt like Siegel and co. fundamentally understood both the Mac and the needs of programmers.
These days I keep BBedit around for its excellent diff tool, syntax-highlighted multi-file grep search and replace, and its decent project browsing. But it's mostly a supplement to vim (MacVim), which I use all the time when I'm actually in there editing text.
My first dedicated text editor was BBedit (when it was still freeware), and for many years had extended experiments with other editors, always eventually returning to BBEdit. Something about it always clicked with me, and I felt like Siegel and co. fundamentally understood both the Mac and the needs of programmers.
These days I keep BBedit around for its excellent diff tool, syntax-highlighted multi-file grep search and replace, and its decent project browsing. But it's mostly a supplement to vim (MacVim), which I use all the time when I'm actually in there editing text.
It’s great that people are so inspired by Vim that they continue to create new plugins, tutorials and websites like Vim Awesome: http://vimawesome.com
Thanks for the link. I checked it out today and was finally able to convert from pathogen to Vundle. The site gives you the exact strings to configure the plugins in all the major plugin managers. IIRC, it scans github looking for .vimrc files and indexes them to gather usage data. Very cool.
What has been amazing so far is that even after using vim for almost 3 years, I'd been sort of afraid of diving deep into the config system (I made do with copy-pasting some popular vimrc files) and it was good enough, but in the short span of 2 days, I've actually gotten to know more about emacs configuration style than I ever did about vim. And I suspect it will only get better as I start to learn Emacs Lisp.