So I use emacs with viper and it's great. I have no idea how to really edit text in emacs without vi mode and I can't open a file in vim without :q and running it again with a different argument. Yet I can edit text vi style and use superior (to vim) and convenient emacs features like modes, tramp, buffer management, org-mode…
I've been using it for only few days, but I think evil and Emacs makes a really nice enviroment. I finally managed to get capslock to be the key for evil-normal-state (default is ESC) and the world is a better place now. I recommend giving it a shot :-).
I have the same feeling, that both worlds are appealing. Vim being "Just focus, don't go meta improving your tools your filthy procrastinator" and Emacs being an "comfortable playground". "How is that algorithm again? Let me try something in elisp on the scratch buffer."
I'm trying to use Sublime Text these days (won't ever have Slime to develop Clojure, though).
I just can't get vim's modes - I'm constantly unintentionally entering keystrokes in the wrong mode, especially when I'm concentrating on what I'm doing. Of course emacs also has annoying modes, e.g. if you change your mind half way through a key combination, you are stuck in a mode. Ctrl+G gets you out of it with the result that I'm constantly pressing Ctrl+G in emacs before I do anything to avoid the sting of keystrokes being thrown away.
I'm still waiting for Jef Raskin's modeless editor (there was a project called Archy which is now abandoned).
Yes, I know how to use the editor and use it moderately. I'm saying there's something fundamentally unlearnable about modes for me as I keep making mode related errors after years of using both emacs and vim.
I have the same trouble when I use unconfigured vim. It gets rather better when I give vim stronger visual clues as to which mode it is in, which I seem to remember for no more that 2 seconds otherwise.
The following scripts give the general idea of how to do this:
Also, I gather than the Gnome Vim's colorscheme support allows you to affect the appearance of the whole window, not just the status line or whatever. I don't use it, though.
The solution to this is that when using Vim properly you're always in normal mode except for short bursts of typing. Don't hang around in insert mode. Need to think for a second about what to type next? Get out of insert mode, think, and then enter insert mode again.
The result of this is that "insert mode" stops being so much like a separate mode and starts feeling more like a command itself! It's the difference between:
move over a word
enter insert mode
type "foo"
exit insert mode
move back a word
and
move over a word
insert the word "foo"
move back a word
I totally agree with you for myself, but in order to make a more general point I'm going to have to to point out that people not destined to use vim as their primary editor can get away with doing the exact opposite. That is, they're almost always in insert mode and only briefly go to normal mode to change something.
The really important thing with any modal interface is that you have one primary mode which you only leave to accomplish a task and to which you return as soon as the task is done. Even emacs has modes in that you're sometimes, say, doing an incremental search. The important thing is that when you're done you're dropped back to the usual mode by default.
I'd honestly go so far as to say that people who feel they must stay in Insert Mode most of the time should not be using Vim. They're not using Vim; they're pounding a square peg into a circular hole. They should stop pretending that they're using Vim.
I apologize in advance for this ode to Vim, but I feel I should get it off my chest.
I admit, the main reason for me to develop in Vim these days is to simply minimize the number of keystrokes I have to press (and the number of times I have to reach for the mouse), because, due to RSI, I experience a mild, but constant, and noticeable discomfort in my wrists (...and triceps, and shoulder) whenever I type (I distinctly remember I developed it in Eclipse during my Symbian C++ development internship). I honestly tried Emacs a few times because of superior Lisp editing, but it just didn't stick, I just can't bring myself to press more keys than I use to in Vim. Force of habit? Maybe.
I have never expected to be "hooked up" on Vim, but I was. In my first job out of the university I was writing Linux-based embedded software almost exclusively. I could never get used to Linux GUI editors after Visual Studio: the lack of any built-in IDE features and constant switching from the editor to the shell made me switch away to something closer to the shell. The initial discomfort of modal editing was less annoying than the lack of features and the accessibility of shell in Linux GUI editors (Eclipse CDT was a pain to set up and use back in these days). Then the discovery of split windows, regex replacement, folds, macros, ex-mode commands, and extensions made my experience what I then thought tolerable.
The mechanical memory had set in, and, upon moving on to my next job, I discovered that I could no longer use Visual Studio with as much comfort as I used Vim! It was curious, since I've "grown up" as a programmer with Visual Studio in the 4 years at the university.
It has snowballed further since then: remapping ';' to ':', ZQ and ZZ shortcuts, quickfix window, copy-paste registers, more motions with text objects ("delete between {}", "move to next ','", replace "()" with "[]", indent 4 line with "4>>"), sorting selected lines, coming up simple with ad-hoc refactoring functions and macros on the fly, marks, buffer greps, jumping between files with LustyExplorer an NERDTree, plugins (VimScript must die, but while it's there, it does the job), and falling back to the shell where Vim falls short. A few vimgolf (there is a site for this) challenges also added some tricks into my toolbox.
Right now I use Vim whenever I can. It does show its age, especially in areas like REPL, IDE features and code completion (it'll get there, eventually, I hope), but I just don't feel at home using anything else at the moment. I'm always on the lookout on the future of Vim or its next successor.
PS: Disclaimer: I don't necessarily advocate for everyone to learn Vim, it really requires a non-trivial investment of time to establish the necessary mechanical memory, but it was worth it for me personally (I do C, C++ and Python almost exclusively). Depending on your domain and the technology you use, you may be better off using Emacs (Lisp) or VS with Resharper (C#).
Another good alternative is to remap the infrequently used Caps-Lock key to Esc (what Emacs users remapped to Control for ages). http://c2.com/cgi/wiki?RemapCapsLock
I am an avid vimmer, but I sometimes use Emacs. I have capslock mapped to ESC, and it works well in emacs. I am pretty comfortable with C-{some_key}. It's the M-C-{some_key} that are a pain. ESC-C-{some_key} is what I use and since I have my capslock mapped, it's convenient.
I write a lot of shell scripts and C where $UPPER_CASE variables are common. Is it still worth remapping Caps-Lock? (The problem is it would be remapped system-wide, not just in Vim.)
Actually, Ctrl-c is the fastest way to get back to normal mode. Unlike Ctrl-[ and <Esc>, it does not check for abbreviations and does not trigger InsertLeave. And on most keyboards it's even easier to type.
Ctrl-c is not always equivalent to <Esc>. For example, if you hit q: to get the command history editor, Ctrl-c will close that buffer, but <Esc> won't.
Then you'll love http://www.viemu.com/ .... There are so many good things to say about ViEmu that it's hard to know where to begin. I've been a happy ViEmu customer for about three years now. Best $99 I've ever spent, hands-down.
Maybe it will suffice to say: "VisualAssist + ViEmu = <3". They synergize so incredibly well together.
Someday I should record a video of me coding C++ in Visual Studio. In the last 4 days alone, I've written 8,700 lines of C++. No way could I have done that without my precious ViEmu / VAX templates / custom hotkeys. (It's rare to ever need to touch the mouse, which is pretty fabulous.)
At this point, I write systems as fast as I can think, not type.
>Someday I should record a video of me coding C++ in Visual Studio.
Please do. It's should not be that difficult to just switch on the recording software and upload it into Youtube. If you could also verbally describe what you're doing and how, would be appreciated.
Another vote for ViEmu. They offer a discount for students if you ask them, and I've been using my copy since senior year. It does lack a few of the subtle details; most annoyingly to me is the lack of leader key mapping to automate common commands. But it's an extremely good replacement for those times when you need to use VS.
Seriously, I think Vim is more dangerous than Emacs for RSI in some respects. Emacs forces you to change your hands' positions as you alternate modifiers. This means that your hands do move more, but they on the balance do given actions less.
At least that's my impression. Obviously there's a lot of posture issues, and you can mitigate RSI to some degree simply by getting up and stretching your hands every 30 minutes. But it's not a simple matter of moving less -> less RSI. If you don't dramatically reduce the number of actions, moving less can be a problem.
Bit your tongue. You only have to change your hand position if you have the modifiers mapped wrong. Ctrl goes next to "A", Meta is below slash (some keyboards have this as an Alt already, sometimes you have to remap it). The modifiers are on opposite pinkies.
Bit your tongue. You only have to change your hand position if you have the modifiers mapped wrong. Ctrl goes next to "A", Meta is below slash (some keyboards have this as an Alt already, sometimes you have to remap it). The modifiers are on opposite pinkies.
I noticed recently that you can use the ex commands in Emacs without converting the whole editor over to Viper. This is really the part of vi that I find attractive. Notes:
Aren't Emacs and Vim basically the same editor at this point?
There are some stylistic differences, which can be surprisingly subtle, like the differences between acoustic and electric guitar.
But pretty much every other editor these days wants to be an MP3 player.
Today's editor war is between (a.) technical people who expect to spend many hours a day manipulating text for the next few decades, and (b.) people who don't ever want to think about text editing because it seems low-level and boring.
Emacs is an interactive Lisp interpreter. Once you realize that you can change function and variable bindings on the fly, you can do anything.
Vim is "merely" an editor with an acceptable scripting language and incredible keyboard shortcuts. The shortcuts have survived for 40 years due to their ease of use and intuitive nature.
The only similarities between Vim and Emacs are their ages and the fantastic communities surrounding each of them.
The only similarities between Vim and Emacs are their ages and the fantastic communities
- both require a large investment to achieve mastery.
- both deliver excellent return on that investment. Proficient use "looks like magic."
- both include (seriously underrated) tutorial software to get new users up and running.
- both are still described as "hard to learn" by people who don't use them.
- both have more popular competitors that are less capable but easier to pick up and use without thinking about it (various IDEs for Emacs, pico/nano for vim).
I don't know what your problem is here, but you'd do better stating it outright. As it is, you're just embarrassing yourself. If age and community are the only similarities between Vim and and Emacs, the one of them is not a Unix text editor.
You are being too emotional about this conversation between you Nyellin. Your original post was flawed - whether it was your understanding or the way you wrote it (I don't know which).
- both require a large investment to achieve mastery.
You don't have to achieve mastery in order to be productive in Emacs and Vim!!! Use Emacs for a solid month and you will be productive in it (like wise for Vim).
- both deliver excellent return on that investment. Proficient use "looks like magic."
This is true (of more things than just Emacs and Vim).
- both include (seriously underrated) tutorial software to get new users up and running.
This is also true (of more software than just Emacs and Vim).
- both are still described as "hard to learn" by people who don't use them.
Because most people have commitment issues and would prefer their IDE's (just like people who don't know how to use the terminal all of the Unix tools (sed/awk/grep/&c... complain it's "hard to learn").
- both have more popular competitors that are less capable but easier to pick up and use without thinking about it (various IDEs for Emacs, pico/nano for vim).
There are no competitors to Emacs and Vim that I'm aware of (the only one to Emacs I can think of and it still isn't a competitor is Yii); IDE's aren't even in the same camp - IDE's are more project management than editor.
[edit] I take this back, there's one piece of software I remember vaguely that is trying to be an IDE with Emacs/Vim style editing, I'm not sure if it provides the type of editing functionality Emacs and Vim do though.
I don't know what your problem is here, but you'd do better stating it outright. As it is, you're just embarrassing yourself. If age and community are the only similarities between Vim and and Emacs, the one of them is not a Unix text editor.
You're actually the one embarrassing yourself, not because of your lack of knowledge but because of your response! Nyellin gave a perfectly good comment to your flawed comment and you reacted emotionally instead of rationally.
Your reasons above for why they are similar are very much moot points - most of those points can be said for many things other than text editors. See my comment for why they ARE DIFFERENT; Nyellin could have gone into more depth as to why they are different, but ultimately he's kind of right. They have both been around forever, they both have HUGE, vibrant, and passionate communities, and they both edit text.
Please note, we are talking about "text editing" and not the gobldegook that is IDE "project management" (IDE's aren't proper text editors, they are stunted text editors).
Your understanding is very much flawed. (FYI, Emacs has been my primary editor for 5 years and Vim has been my over-ssh editor for 6)
Your guitar analogy is more applicable not between Emacs and Vim but between something like pico/nano and vim/emacs. It's hard to find a good analogy between Emacs and Vim because they are both awesome editors for many different reasons.
Emacs (due to its LISP origins) is highly configurable, probably the most configurable piece of software you will ever use that has a large mindshare and presence in the community. Vim is configurable, but Vim's intention from the beginning was to be an efficient editor over SSH; it just so happens people are now using it as their primary editor of choice on their desktops.
With Vim you can't just start editing text right away (like Emacs, Word, TextEdit &c...) you have to switch from the Console Mode into Editing Mode (by pressing "i" on most installs). Then if you want to delete a few words you have to switch back to the Console Mode (by pressing "esc" usually) position your cursor, and enter "wq" until the words you wanted deleted are deleted. This has the benefit of separating commands from text editing so there are no "control" keys as you will see with Emacs.
With Emacs you can edit text right away and there are no "modes" to change. Emacs instead has control keys (the two main ones are "C" and "M" - on your keyboard that's "Control" and "Alt" - I've remapped my control key to be the Caps Lock key since it makes my pinky finger less angry). So if while I'm editing I wanted to delete a few words, I would position my cursor then hold down Alt and press "d" until the words I wanted deleted are deleted (in emacs lingo: "M-d"). This has the benefit of not "context" switching into other modes but it means you now have to be very clever with your key combinations so you don't end up playing Twister! on your keyboard for more complicated tasks (that's why some people prefer Vim because it negates that problem with "modes").
Emacs doesn't want to be an MP3 player - Emacs wants to be whatever the person using it wants it to be. To me that's what wins me over to Emacs; if I need my editor to do something that it doesn't do stock, I have the full power to add/change/remove whatever it is I want it to do. Additionally there's an enormous community of people with far more knowledge and experience in doing that to tap into, plus, if you want it do something it's most likely someone already has done (and done it better).
Vim also doesn't want to be an MP3 player - matter of fact, you would get stoned by the Vim community for saying that, those guys are all about efficiency. I love Vim because of its efficiency - I actually really hate Emacs over SSH (to all those saying "use TRAMP!" I have, and it's not nearly as cool as using Vim over SSH). My editor of choice when working directly on a server editing code is Vim, it's fast, concise, and very powerful.
There is no editor war today - there's the never ending jihad between annoying emacs users and vim users that think their editor of choice is better than the other (I think those people are stupid, because BOTH EDITORS ARE AMAZING and EVERYONE HAS A DIFFERENT PREFERENCE). Technical people use editors that empower them to write software; people who don't want to think about text editing are still keyboard pecking when writing their emails.
emacs originated as the tool of choice for programmers. In those days a programmer would sit at a single text-based terminal all day, working dawn-til-dusk in a single editor process on a complex set of files stored on one system. emacs was designed to be an all-encompassing and extensible environment, because the programmer had the time and skills to sculpt his environment for maximum efficiency - and because the operating system shell was extremely basic in those days.
vim arose as a sysadmin's tool. Unlike programmers, sysadmins were constantly moving between systems and performing a variety of simple edits on various text files. They needed an extremely quick editor with sensible defaults, because they wouldn't be working on a single system long enough or doing anything complex enough to benefit from a customized environment.
Which editor is superior today depends on which archetype a particular user resembles. If someone isn't interested in crafting emacs into a cybernetic extension of their own mind, they're missing the point and should probably stick with vim for its sensible out-of-the-box behavior. They're both strictly superior to every other text editor available, because they're both fully accessible through keystrokes.
You're acting like I've never heard of either Emacs or Vim before, and you shouldn't do that. The net effect is to make HN less fun and less useful for everyone.
Because the next time I think about starting a conversation on, say, similarities and differences between successful, competing software packages and the cognitive models they encourage...
I'll remember that this time, when I tried to keep my opening post friendly, informal, and solicitous, you assumed I was an idiot.
I'll be sure not to make jokes when I think someone else is getting too uptight, because jokes are emotional and text editors are serious business.
And most importantly, next time I'll establish my credentials up front, by prepending everything in my .emacs.d to all my posts. It's a little verbose, but it means nobody gets insulted by being mistaken for a n00b.
Plus, in Conkeror, it's really easy to write a regex that will detect 30,000 lines of custom elisp and set it to {display:none;}.
Is this in response to my other comment or this direct comment? Nothing about the comment you are responding to here is attacking you. Your understanding (or writing, as I said) is flawed. Maybe you aren't a noob and you just aren't expressing yourself well enough.
Your comment wasn't "unfriendly" it just wasn't enlightening. I did not assume you were an idiot and no where in my comment did I insinuate that.
Nothing about an .emacs.d proves you are a competent emacs user - I've seen some hideous init files come from Emacs noobs and hideous init files come from power users!
Depends on what you mean by jokes - Hacker News (less so now than a few years ago) tends to be a serious forum for discussion; reddit-esque joking around is both frowned upon and discouraged. Although, TBH I didn't see any "jokes" coming from you at all. I wasn't responding to your jokes (unless you're talking about my other comment in response to you).
First, phrases like "your understanding is flawed" and "maybe you just aren't expressing yourself well enough" are way outside the bounds of civil conversation.
Second, how would you unpack this sentence?
"Aren't black and white basically the same color these days?"
Any discussion of Vim that lacks mention of text objects is under serving the editor. Text objects and repeat are by far the best features of the editor.
I'm curious if the speed difference between counting how many times to repeat a command versus using movement/visual block/etc. is big enough?
I find the "repeat-n-times" modifiers require a lot of thought before I know what number to put before the command. I do consider myself very fast with Vim, but the repeat commands haven't done much for me.
Likewise. I very, very seldom find myself using repetitions. I mostly use simple commands or text objects, and when those don't cover some weird case I fall back to visual mode.
Occasionally I know I want to delete just 2 words and so use d2w or something, but that's so rare I really notice when it happens.
There's a great deal of power in '.', which repeats the last command. So if you have to do something 12 times, your steps could look something like this;
- Run the command once
- Think "Hmm, looks like I have to do this about ten more times"
- Type '10.', repeating the last command 10 times
- See that there's only one left to do, since you guessed 10 and it was 11
- Press '.' one more time to do the last one
You won't win any vim golf competitions like that, but it's very easy to do.
Actually, 10. doesn't necessarily repeat the last command 10 times, it just runs it again with an argument of 10. For example ">>10." will indent the current line and then indent it and the following 9 lines.
I still haven't found an easy way to indent a line N times without pressing ">" 2N times...
Activate visual mode first. In visual mode, the argument is used for the number of indents (because the lines to indent are selected visually).
So to indent the current line 4 times, type: "V4>". Happy vimming! :)
What I do regularly is to record a macro that combines some action with a movement. For example, I have some file with many many lines that need to be changed in a very similar fashion. (Recent example: ten comma separated numbers per line, all wrong by a factor of ten, 100 lines of those).
I will record that macro, then repeat it 100 times. Since every command includes a movement at the end (say, a "j"), this will change 100 lines (or words, or regex finds, or whatever).
Damn, I instinctively hit <ESC> after writing that last line.
I was a long-time Vim user (around 10 years or so) and switched to Emacs in order to use Lisp + Slime in order to win an argument about Lisp. What's important is that I lost that argument, like Lisp, and use Emacs as my primary editor now.
However, the Vim keybindings are still etched upon my soul so I still find myself popping it open for quick-and-dirty edits.
They're both good editors and I like the conclusion of this article.
I'm also an Emacs user, but I've been curious about Vi. Have you tried using Viper? As somebody with experience in both, do you think it's something worth trying?
I'm not going to bother asking why Vim/Vi is interesting to you, but in answer to your question: No.
I immediately went for the Viper-mode Vi emulation and it's not good. Go whole-hog. Just dive into the deep end and start swimming.
The reason for that is that the emulation layer lives in a limbo that is half-emacs-half-vi. The modes don't work the same way. And I'd be wary of falling back on Emacs instead of learning the Vi way.
If you really want to try to transition to a new editor, I would open up a fresh install of Vim and start with the in-editor tutorial.
These "I've used vim/emacs and decided to try switching..." articles always leave me cold.
I mean, both are insanely powerful editors. It's not as if there is something one can do that the other cannot, and if there is, it's doubtful that a user would want to -- for example, I don't think vim has a built in email client, but the vim users I've talked to laugh at the idea of an email client in their editor.
As a result, all of these "I've switched" articles begin with a comparison of modal and non-modal editing, discuss some pros and cons of both, and end with the same conclusion: both are great editors!
While I generally agree with your sentiment, I will say that I use http://danielchoi.com/software/vmail.html Vmail (vim-gmail) daily and quite like it. Some of us don't mind Vim throwing in the proverbial kitchen sink :)
I used emacs for a while, but fairly recently I switched to vim for one simple reason: opening speed. Emacs always takes a while to launch, but no matter how many plugins and whatnot I install in Vim it always launches instantly. And that, to me, is worth learning a new editor.
Most of the time I'm just running /usr/bin/emacs which is non-GUI by default. A fast boot for me is about a second, a cold boot is a couple seconds. That's acceptable if I'm doing editing that will take a while, but it's interminable when I'm expecting to pop in and out of the editor frequently (e.g. writing very quick git commit messages). Vim's fast boot is near-instantaneous, and the cold boot is less than a second.
I don't like that because it forces all of my editing into one terminal window (or into GUI emacs if I use that as the server). I want to be able to pop open emacs in other terminal windows quickly.
Seconded. The direction keys (j, l, I think, and I forget which the other two were; I just kept the mapping from movement-of-fingers to movement-of-cursor) may not be as intuitive as they are in qwerty, but after a short while you just ingrain them in your muscle memory and it doesn't matter anymore.
I've been a vim user for about 10 years now. I've recently started using emacs for lisp/SLIME dev. The number one feature I miss when I'm in emacs land is vim's "i" and "a" commands.
di" deletes everything between the double quotes.
da" deletes everything between including the double quotes themselves
It works with other matching pairs as well (ie di(, di[ di'). I use it constantly. I've searched and search, and have not been able to find an emacs equivalent.
65 comments
[ 3.2 ms ] story [ 42.2 ms ] thread:e filename
I'm trying to use Sublime Text these days (won't ever have Slime to develop Clojure, though).
I'm still waiting for Jef Raskin's modeless editor (there was a project called Archy which is now abandoned).
The following scripts give the general idea of how to do this:
1. http://vim.wikia.com/wiki/Change_statusline_color_to_show_in...
2. http://www.vim.org/scripts/script.php?script_id=3165
Also, I gather than the Gnome Vim's colorscheme support allows you to affect the appearance of the whole window, not just the status line or whatever. I don't use it, though.
The result of this is that "insert mode" stops being so much like a separate mode and starts feeling more like a command itself! It's the difference between:
andThe really important thing with any modal interface is that you have one primary mode which you only leave to accomplish a task and to which you return as soon as the task is done. Even emacs has modes in that you're sometimes, say, doing an incremental search. The important thing is that when you're done you're dropped back to the usual mode by default.
For more on the theory of modal interfaces, see here: http://www.osnews.com/story/18904/pt_V_Modes
I admit, the main reason for me to develop in Vim these days is to simply minimize the number of keystrokes I have to press (and the number of times I have to reach for the mouse), because, due to RSI, I experience a mild, but constant, and noticeable discomfort in my wrists (...and triceps, and shoulder) whenever I type (I distinctly remember I developed it in Eclipse during my Symbian C++ development internship). I honestly tried Emacs a few times because of superior Lisp editing, but it just didn't stick, I just can't bring myself to press more keys than I use to in Vim. Force of habit? Maybe.
I have never expected to be "hooked up" on Vim, but I was. In my first job out of the university I was writing Linux-based embedded software almost exclusively. I could never get used to Linux GUI editors after Visual Studio: the lack of any built-in IDE features and constant switching from the editor to the shell made me switch away to something closer to the shell. The initial discomfort of modal editing was less annoying than the lack of features and the accessibility of shell in Linux GUI editors (Eclipse CDT was a pain to set up and use back in these days). Then the discovery of split windows, regex replacement, folds, macros, ex-mode commands, and extensions made my experience what I then thought tolerable.
The mechanical memory had set in, and, upon moving on to my next job, I discovered that I could no longer use Visual Studio with as much comfort as I used Vim! It was curious, since I've "grown up" as a programmer with Visual Studio in the 4 years at the university.
It has snowballed further since then: remapping ';' to ':', ZQ and ZZ shortcuts, quickfix window, copy-paste registers, more motions with text objects ("delete between {}", "move to next ','", replace "()" with "[]", indent 4 line with "4>>"), sorting selected lines, coming up simple with ad-hoc refactoring functions and macros on the fly, marks, buffer greps, jumping between files with LustyExplorer an NERDTree, plugins (VimScript must die, but while it's there, it does the job), and falling back to the shell where Vim falls short. A few vimgolf (there is a site for this) challenges also added some tricks into my toolbox.
Right now I use Vim whenever I can. It does show its age, especially in areas like REPL, IDE features and code completion (it'll get there, eventually, I hope), but I just don't feel at home using anything else at the moment. I'm always on the lookout on the future of Vim or its next successor.
PS: Disclaimer: I don't necessarily advocate for everyone to learn Vim, it really requires a non-trivial investment of time to establish the necessary mechanical memory, but it was worth it for me personally (I do C, C++ and Python almost exclusively). Depending on your domain and the technology you use, you may be better off using Emacs (Lisp) or VS with Resharper (C#).
Getting out of insert mode with a double j instead of moving your hand (esc) or doing the slightly awkward ctrl+[ is a godsend.
Maybe it will suffice to say: "VisualAssist + ViEmu = <3". They synergize so incredibly well together.
Someday I should record a video of me coding C++ in Visual Studio. In the last 4 days alone, I've written 8,700 lines of C++. No way could I have done that without my precious ViEmu / VAX templates / custom hotkeys. (It's rare to ever need to touch the mouse, which is pretty fabulous.)
At this point, I write systems as fast as I can think, not type.
Please do. It's should not be that difficult to just switch on the recording software and upload it into Youtube. If you could also verbally describe what you're doing and how, would be appreciated.
It's not perfect, but in my opinion it is certainly the best free option available. I have never used ViEmu, so I can't compare it to that.
At least that's my impression. Obviously there's a lot of posture issues, and you can mitigate RSI to some degree simply by getting up and stretching your hands every 30 minutes. But it's not a simple matter of moving less -> less RSI. If you don't dramatically reduce the number of actions, moving less can be a problem.
http://www.advogato.org/person/chalst/diary/277.html
That said, vim's command set is a superset of ex, and includes some nice things that the above misses.
There are some stylistic differences, which can be surprisingly subtle, like the differences between acoustic and electric guitar.
But pretty much every other editor these days wants to be an MP3 player.
Today's editor war is between (a.) technical people who expect to spend many hours a day manipulating text for the next few decades, and (b.) people who don't ever want to think about text editing because it seems low-level and boring.
Emacs is an interactive Lisp interpreter. Once you realize that you can change function and variable bindings on the fly, you can do anything.
Vim is "merely" an editor with an acceptable scripting language and incredible keyboard shortcuts. The shortcuts have survived for 40 years due to their ease of use and intuitive nature.
The only similarities between Vim and Emacs are their ages and the fantastic communities surrounding each of them.
- both require a large investment to achieve mastery.
- both deliver excellent return on that investment. Proficient use "looks like magic."
- both include (seriously underrated) tutorial software to get new users up and running.
- both are still described as "hard to learn" by people who don't use them.
- both have more popular competitors that are less capable but easier to pick up and use without thinking about it (various IDEs for Emacs, pico/nano for vim).
I don't know what your problem is here, but you'd do better stating it outright. As it is, you're just embarrassing yourself. If age and community are the only similarities between Vim and and Emacs, the one of them is not a Unix text editor.
- both require a large investment to achieve mastery.
You don't have to achieve mastery in order to be productive in Emacs and Vim!!! Use Emacs for a solid month and you will be productive in it (like wise for Vim).
- both deliver excellent return on that investment. Proficient use "looks like magic."
This is true (of more things than just Emacs and Vim).
- both include (seriously underrated) tutorial software to get new users up and running.
This is also true (of more software than just Emacs and Vim).
- both are still described as "hard to learn" by people who don't use them.
Because most people have commitment issues and would prefer their IDE's (just like people who don't know how to use the terminal all of the Unix tools (sed/awk/grep/&c... complain it's "hard to learn").
- both have more popular competitors that are less capable but easier to pick up and use without thinking about it (various IDEs for Emacs, pico/nano for vim).
There are no competitors to Emacs and Vim that I'm aware of (the only one to Emacs I can think of and it still isn't a competitor is Yii); IDE's aren't even in the same camp - IDE's are more project management than editor.
[edit] I take this back, there's one piece of software I remember vaguely that is trying to be an IDE with Emacs/Vim style editing, I'm not sure if it provides the type of editing functionality Emacs and Vim do though.
I don't know what your problem is here, but you'd do better stating it outright. As it is, you're just embarrassing yourself. If age and community are the only similarities between Vim and and Emacs, the one of them is not a Unix text editor.
You're actually the one embarrassing yourself, not because of your lack of knowledge but because of your response! Nyellin gave a perfectly good comment to your flawed comment and you reacted emotionally instead of rationally.
Your reasons above for why they are similar are very much moot points - most of those points can be said for many things other than text editors. See my comment for why they ARE DIFFERENT; Nyellin could have gone into more depth as to why they are different, but ultimately he's kind of right. They have both been around forever, they both have HUGE, vibrant, and passionate communities, and they both edit text.
Please note, we are talking about "text editing" and not the gobldegook that is IDE "project management" (IDE's aren't proper text editors, they are stunted text editors).
Your guitar analogy is more applicable not between Emacs and Vim but between something like pico/nano and vim/emacs. It's hard to find a good analogy between Emacs and Vim because they are both awesome editors for many different reasons.
Emacs (due to its LISP origins) is highly configurable, probably the most configurable piece of software you will ever use that has a large mindshare and presence in the community. Vim is configurable, but Vim's intention from the beginning was to be an efficient editor over SSH; it just so happens people are now using it as their primary editor of choice on their desktops.
With Vim you can't just start editing text right away (like Emacs, Word, TextEdit &c...) you have to switch from the Console Mode into Editing Mode (by pressing "i" on most installs). Then if you want to delete a few words you have to switch back to the Console Mode (by pressing "esc" usually) position your cursor, and enter "wq" until the words you wanted deleted are deleted. This has the benefit of separating commands from text editing so there are no "control" keys as you will see with Emacs.
With Emacs you can edit text right away and there are no "modes" to change. Emacs instead has control keys (the two main ones are "C" and "M" - on your keyboard that's "Control" and "Alt" - I've remapped my control key to be the Caps Lock key since it makes my pinky finger less angry). So if while I'm editing I wanted to delete a few words, I would position my cursor then hold down Alt and press "d" until the words I wanted deleted are deleted (in emacs lingo: "M-d"). This has the benefit of not "context" switching into other modes but it means you now have to be very clever with your key combinations so you don't end up playing Twister! on your keyboard for more complicated tasks (that's why some people prefer Vim because it negates that problem with "modes").
Emacs doesn't want to be an MP3 player - Emacs wants to be whatever the person using it wants it to be. To me that's what wins me over to Emacs; if I need my editor to do something that it doesn't do stock, I have the full power to add/change/remove whatever it is I want it to do. Additionally there's an enormous community of people with far more knowledge and experience in doing that to tap into, plus, if you want it do something it's most likely someone already has done (and done it better).
Vim also doesn't want to be an MP3 player - matter of fact, you would get stoned by the Vim community for saying that, those guys are all about efficiency. I love Vim because of its efficiency - I actually really hate Emacs over SSH (to all those saying "use TRAMP!" I have, and it's not nearly as cool as using Vim over SSH). My editor of choice when working directly on a server editing code is Vim, it's fast, concise, and very powerful.
There is no editor war today - there's the never ending jihad between annoying emacs users and vim users that think their editor of choice is better than the other (I think those people are stupid, because BOTH EDITORS ARE AMAZING and EVERYONE HAS A DIFFERENT PREFERENCE). Technical people use editors that empower them to write software; people who don't want to think about text editing are still keyboard pecking when writing their emails.
emacs originated as the tool of choice for programmers. In those days a programmer would sit at a single text-based terminal all day, working dawn-til-dusk in a single editor process on a complex set of files stored on one system. emacs was designed to be an all-encompassing and extensible environment, because the programmer had the time and skills to sculpt his environment for maximum efficiency - and because the operating system shell was extremely basic in those days.
vim arose as a sysadmin's tool. Unlike programmers, sysadmins were constantly moving between systems and performing a variety of simple edits on various text files. They needed an extremely quick editor with sensible defaults, because they wouldn't be working on a single system long enough or doing anything complex enough to benefit from a customized environment.
Which editor is superior today depends on which archetype a particular user resembles. If someone isn't interested in crafting emacs into a cybernetic extension of their own mind, they're missing the point and should probably stick with vim for its sensible out-of-the-box behavior. They're both strictly superior to every other text editor available, because they're both fully accessible through keystrokes.
Because the next time I think about starting a conversation on, say, similarities and differences between successful, competing software packages and the cognitive models they encourage...
I'll remember that this time, when I tried to keep my opening post friendly, informal, and solicitous, you assumed I was an idiot.
I'll be sure not to make jokes when I think someone else is getting too uptight, because jokes are emotional and text editors are serious business.
And most importantly, next time I'll establish my credentials up front, by prepending everything in my .emacs.d to all my posts. It's a little verbose, but it means nobody gets insulted by being mistaken for a n00b.
Plus, in Conkeror, it's really easy to write a regex that will detect 30,000 lines of custom elisp and set it to {display:none;}.
Your comment wasn't "unfriendly" it just wasn't enlightening. I did not assume you were an idiot and no where in my comment did I insinuate that.
Nothing about an .emacs.d proves you are a competent emacs user - I've seen some hideous init files come from Emacs noobs and hideous init files come from power users!
Depends on what you mean by jokes - Hacker News (less so now than a few years ago) tends to be a serious forum for discussion; reddit-esque joking around is both frowned upon and discouraged. Although, TBH I didn't see any "jokes" coming from you at all. I wasn't responding to your jokes (unless you're talking about my other comment in response to you).
Second, how would you unpack this sentence?
"Aren't black and white basically the same color these days?"
I find the "repeat-n-times" modifiers require a lot of thought before I know what number to put before the command. I do consider myself very fast with Vim, but the repeat commands haven't done much for me.
Occasionally I know I want to delete just 2 words and so use d2w or something, but that's so rare I really notice when it happens.
- Run the command once
- Think "Hmm, looks like I have to do this about ten more times"
- Type '10.', repeating the last command 10 times
- See that there's only one left to do, since you guessed 10 and it was 11
- Press '.' one more time to do the last one
You won't win any vim golf competitions like that, but it's very easy to do.
I still haven't found an easy way to indent a line N times without pressing ">" 2N times...
I will record that macro, then repeat it 100 times. Since every command includes a movement at the end (say, a "j"), this will change 100 lines (or words, or regex finds, or whatever).
Damn, I instinctively hit <ESC> after writing that last line.
I was a long-time Vim user (around 10 years or so) and switched to Emacs in order to use Lisp + Slime in order to win an argument about Lisp. What's important is that I lost that argument, like Lisp, and use Emacs as my primary editor now.
However, the Vim keybindings are still etched upon my soul so I still find myself popping it open for quick-and-dirty edits.
They're both good editors and I like the conclusion of this article.
I immediately went for the Viper-mode Vi emulation and it's not good. Go whole-hog. Just dive into the deep end and start swimming.
The reason for that is that the emulation layer lives in a limbo that is half-emacs-half-vi. The modes don't work the same way. And I'd be wary of falling back on Emacs instead of learning the Vi way.
If you really want to try to transition to a new editor, I would open up a fresh install of Vim and start with the in-editor tutorial.
I mean, both are insanely powerful editors. It's not as if there is something one can do that the other cannot, and if there is, it's doubtful that a user would want to -- for example, I don't think vim has a built in email client, but the vim users I've talked to laugh at the idea of an email client in their editor.
As a result, all of these "I've switched" articles begin with a comparison of modal and non-modal editing, discuss some pros and cons of both, and end with the same conclusion: both are great editors!
Where's the beef?
di" deletes everything between the double quotes. da" deletes everything between including the double quotes themselves
It works with other matching pairs as well (ie di(, di[ di'). I use it constantly. I've searched and search, and have not been able to find an emacs equivalent.
[1] http://www.gnu.org/s/libtool/manual/emacs/Expressions.html