Why I can’t stop using Vim(kornerstoane.com) |
Why I can’t stop using Vim(kornerstoane.com) |
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.
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
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.
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)
Regular etags called with the emacs bindings worked just fine, but switching contexts from evil mode was a pain.
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.
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.
It's like the nostalgia I get when the seasons change, and for a few days I can feel my childhood.
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.
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.
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.
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 :)
Add MELPA to your package sources, then just M-x list-packages here and there and check out anything new that looks cool.
:wq
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...
(It's the same as :wq, but one character shorter.)
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.
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.
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.
[0] http://armedbear-j.sourceforge.net/
[1] https://github.com/kevinkrouse/j/tree/master/jFor 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.
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 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-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 = NULBut 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.
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.
Is using macros' really common? I haven't yet figured out in when and where to use macros during my workflow.
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 :)
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.
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.
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!
Many ways to edit a cat.
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.
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.
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.
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.
It took production down for 30 minutes until I noticed it. Remember, kids! ":set paste".
Interesting, I was thinking something similar - suitability for maintenance vs from scratch.
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.
gg beats both (I don't think I've ever used 1G to jump to the top of the file)
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 :)
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.
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?
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?
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 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 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.
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.
Anyway today we can just sshfs and use even a random ide for everything so... we can do as we like.
Is that correct?
Sorry if this offends you, but how can you consider your self a programmer when you don't know how to use a terminal?
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.
The keyboard allows you to navigate too, without the need for a mode.
"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.)
One measure of effectiveness would be: to count the number of keystrokes needed to do something in vi compared to other editors.
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
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.
Having modes in a text editor also makes sense; modes provide affordances to get certain things done.
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.
And (c) about editing. Why type an extra character (i for insert) to let you insert? Why not just type to insert?
Most vim users are only in insert mode when... inserting text.
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 .
And on the flip side I have also met a number of (relative) dullards whose shell skills were unquestionable.
> 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.
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...
(For the record - I think it was a legitimate question. Upvoted!)
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.
Downvoting happens to everybody, and most unfair downvotes are corrected after a while by other users, rendering the complaint even more pointless.
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.
noremap \ :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)
: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.
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 just tried it, it doesn't work :( That's too bad.
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...
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?
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.
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 :)
Also, you can have this in your vimrc:
set clipboard=unnamedplus
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?