為什麼這麼多人喜歡使用 Vim 或 Emacs？
為什麼那麼多人非要把vim或emacs配成IDE那樣，而不使用現成的很完善的IDE？感覺這樣有時候真的很分散注意力和影響效率，當然我不反對把vim或emacs作為簡單的編輯器使用
Vim 是很完美的跨平台文本編輯器，無論在Mac, Ubuntu, Windows上，甚至可以直接在伺服器平台 Unix, FreeBSD等直接配置使用，而且配置文件大同小異，操作習慣基本相同。
同時，在Mac， *nix 平台，使用「:!」命令就等同於在編輯器里，幾乎可以使用外部的shell命令，無需在執行命令時再打開一個shell窗口。（當然如果是Windows就等同於可以執行命令提示符下的命令）
游標定位，查找，替換，autocmd，多窗口編輯，正則表達式，從這些隨意拉出的特性去挖掘，你會發現，「哇，原來文本編輯器也有會這麼強大，別有洞天。
歷史悠久，插件齊全，完善的配置，既能達到華麗的外觀（配色方案），又能幾乎達到Mac下另一神器 TextMate 的重要功能，如有興趣，充分嘗試了才知道她的迷人之處。一步到位用 vim/emacs，它讓你更專註你要做的事情本身。
作為一個程序員來說，或者作為一個立志成為黑客的人來說，編輯器是你的基礎工具，是你必須得絕對熟練掌握的東西，你必須絕對的完全的熟練掌握它，它將伴隨你很多年。——一個優秀的設計必須是從一開始就具有優秀的機制，容易被無限的擴展而不喪失兼容。而 vim/emacs 這樣的工具，一旦你掌握，在未來的三十年里你都不用再操心編輯器的問題。
如果你使用 IDE，它通常是一直在變化中的，而且一直變化中的 IDE 在編輯器這個單項指標上始終無法與專業編輯器相比擬，在編程生涯中你將始終需要操心編輯器的問題。始終需要面臨不同的環境。這使你難以集中精力在最應當注意的地方。
如果一個雕刻師每次工作的時候都需要先去學習和適應那把刀，他能有很好的效率嗎？不，他通常會有自己最習慣的那套刀具，裡面不少組件常常是由自己打磨，並且伴隨自己非常長的時間。。。Emacs/Vi/Vim都是屬於那個神奇的年代之中的那些個傳奇的程序員之手。你要知道在那個年代編程不是件容易的事情，沒有IDE這個萬能保姆來幫你自動完成這，自動完成那，自動到到底完成了什麼你自己也不知道。那個年代大家輪著排大型機上好似網吧，哪怕你是富豪有台個人計算機，它也不會比現在小販手裡的山寨手機強多少。每個人寫程序的時候都在絞盡腦汁的縮減每一點代碼，壓低每一點CPU/內存消耗，優化每一點演算法。
So，那個年代的程序員是個相當變態的工作，對個人的職業素養要求相當之高。他們的腦子比IDE強大，自己寫代碼能倒著背出來，壓根用不上什麼全自動保姆，出門上朋友家沒帶軟盤，分分秒寫出一個跟家裡連一個空格都不差的程序。家裡沒有終端機，打電話翻雜誌郵購零件自己揮舞著烙鐵在車庫裡自己烙一個。想上網了，買個貓回家，發現沒有自己系統的驅動，立馬抄出Emacs/Vi/Vim揮舞著自己的手指碼一個。
現在的計算機性能都NB了，少花一個月錢就能攢出一台計算機，連樓下賣菜的大媽都用上智能手機了。現在的IDE多如牛毛，各種智能補全，各種智能調試，各種自動化，恨不得讓你點幾下滑鼠就能自動出來一個程序。現在的各種框架都以能自動生成紅樓夢那麼長的代碼為榮，以讓你多敲兩件鍵盤為恥，巴不得能讓你在一夜之間就能「自動」寫出能承受百萬級訪問數量的Web程序來。
現在的程序員浮躁的不得了，上網各種庫，框架，能有的全得有，往鍋里一扔熬上個把小時就能出一個程序，但是他們真的知道自己在幹什麼嗎？他們真的知道自己寫出來的到底是個嘛玩意兒嘛？
都說現在是程序員的"黃金"年代，但是在我眼裡「有錢的暴發戶多了，真正的傳奇已經很久未見過了.」不管你現在使用什麼編輯器，如果你追求高效率的文本編輯，最終你會找到vim/emacs上來，然後就到頭了，後面沒有了。
不管你現在使用什麼編輯器，總是會有人過來告訴你XXX編輯器要比你現在用的這個好，如果你不斷順著別人推薦的進行嘗試，最終你會找到vim/emacs上來，然後就到頭了，後面沒有了。也沒有人會過來再告訴你XXX編輯器比你現在用的vim/emacs要好。 Vim/Emacs 可以讓你專註於文本編輯本身。
只使用鍵盤可以讓思維和操作pipeline起來。因為大部分情況下你不需要根據屏幕的反饋來決定下一步怎麼做，這樣大腦好像可以從指導操作中解放出來。而一般的IDE是無法脫離滑鼠的，可用滑鼠操作本身就是效率很低的事情。
用了Vim/Emacs，再加上良好的習慣(Seven habits of effective text editing 2.0)，你這輩子不需要第3個編輯器了。
大學時期花了很多時間折騰vi, 想把vi弄成一個支持c/c++ IDE or Java IDE等等，自己也寫一些腳本
找了各種插件，比如ominicomplete等等類似自動補全的插件，各種tag，各種Project管理。
現在想想真是後悔不已。因為經過無數嘗試後，我最後還是發現寫c/c++ 用VS比用vi方便,寫Java程序eclipse比vi方便，寫php程序Zend比vi方便...
但是編輯長段文字(寫文章，寫需求文檔)，vim是很方便的。
-最後-：
我覺得每個工具都有其擅長和不刪除的地方，我們不應該花過多精力改造之而使其萬能。讓合適的工具辦合適的事情才是真正提高效率的方法。
我經常會一會兒寫點C，一會兒寫點perl，一會兒寫點scheme……
C/C++/perl/mips assembly/是作業，scheme是愛好……
用IDE的話，就得一會兒打開visual studio，一會兒打開perl的什麼解釋器(不曉得perl有什麼IDE，win下面都是用ultraedit或vim調用activeperl），一會兒打開racket......
所以現在更喜歡跑到ubuntu下全都在terminal里搞定……
感覺擼代碼時的體驗是能不用滑鼠就不用滑鼠……
############################################################################
上圖一張, from stackoverflow：
配成IDE那樣倒真不見得比vs更好用，大部分高手一定不是這樣用的。
你確信很多人這樣做？我想是滿足裝b需要。
若是做純粹的文本編輯，這兩個是真正神器。
剛開始是為了裝逼，後來慢慢的，效率太高了，離不開了。
學習曲線陡峭加各種神牛加持
導致：
稍微學了點就可以在別人面前裝逼
也能給自己成就感
這玩樣有癮....
被這個群體的氣質所吸引：
1.追求效率；
2.拒絕重複；
3.熱愛hacking；
4.喜歡挑戰。
關於編輯器的大戰通常都是討論能與不能，其實IDE和文本編輯器都是互相學習借鑒的。但只要看看他們大多數用戶都在以什麼樣的風格做事，你就會發現大大的不同。
如果不限於程序員，其實並不是很多人喜歡用 Vim/Emacs，就我所看到的，喜歡用 UltraEdit/EditPlus/Notepad++/EmEditor 的人多得多，最多的可能是打開 Microsoft Word 當文本編輯器用。
一般對文本編輯器有追求的人，都非常重視操作效率、功能和個性化，嘗試多了自然就會轉向 Vim/Emacs 這種擅長於此道的工具。
你會發現，你想要什麼東西，往往只需要多學習一點、多問一點，或者自己多想想辦法，就能夠得到，不需要切換到另一個完全不同的環境中重新適應。
回答太多了，我沒工夫一點點看，作為一個程序猿，vim是必備技能之一。原因有幾個，
第一，多數的*nix伺服器上都有vim，無限逼近100%；
第二，vim的使用方法和快捷鍵非常穩定，所有的操作系統平台上的vim，用法非常一致，無限逼近相同；
第三，vim是變化中的永恆，世界是瞬息萬變的，每天新軟體，新技術不斷湧現，vim這種軟體，毛估估至少得有10年沒什麼大變化了，至少我用到的部分，沒有什麼變化，而且我覺得再有十年，應該也不會有什麼大變化，如果你很懶惰，學vim是沒錯的，因為學完就沒有更多需要學習的了~更何況，只需要學個10%就可以用得很happy了。
貼一下 VIM 作者的文章：
Seven habits of effective text editing
by Bram Moolenaar
Bram@Moolenaar.net
If you spend a lot of time typing plain text, writing programs or HTML, you can save a lot of time by using a good editor and using it effectively. This paper will present guidelines and hints for doing your work more quickly and with less mistakes.
The open source text editor Vim (Vi IMproved) will be used here to present the ideas about effective editing, but they apply to other editors just as well. Choosing the right editor is actually the first step towards effective editing. The discussion about which editor is the best for you would take too much room and is avoided. If you don"t know which editor to use or are dissatisfied with what you are currently using, give Vim a try; you won"t be disappointed.
Part 1: edit a file
-------------------
1. Move around quickly
Most time is spent reading, checking for errors or looking for the right place to work on, rather than inserting new text or changing it. Navigating through the text is done very often, thus you should learn how to do that quickly.
Quite often you will want to search for some text you know is there. Or look at all lines where a certain word or phrase is used. You could simply use the search command "/pattern" to find the text, but there are smarter ways:
- If you see a specific word and want to search for other occurences of the same word, use the "*" command. It will grab the word from under the cursor and search for the next one.
- If you set the "incsearch" option, Vim will show the first match for the pattern, while you are still typing it. This quickly shows a typo in the pattern.
- If you set the "hlsearch" option, Vim will highlight all matches for the pattern with a yellow background. This gives a quick overview of where the search command will take you. In program code it can show where a variable is used. You don"t even have to move the cursor to see the matches.
In structured text there are even more possibilities to move around quickly. Vim has specific commands for programs in C (and similar languages like C++ and Java):
- Use "%" to jump from a open brace to its matching closing brace. Or from a "#if" to the matching "#endif". Actually, "%" can jump to many different matching items. It is very useful to check if () and {} constructs are balanced properly.
- Use "[{" to jump back to the "{" at the start of the current code block.
- Use "gd" to jump from the use of a variable to its local declaration.
There are many more, of course. The point is that you need to get to know these commands. You might object that you can"t learn all these commands - there are hundreds of different movement commands, some simple, some very clever - and it would take weeks of training to learn them all. Well, you don"t need to; instead realize what your specific way of editing is, and learn only those commands that make your editing more effective.
There are three basic steps:
1. While you are editing, keep an eye out for actions you repeat and/or spend quite a bit of time on.
2. Find out if there is an editor command that will do this action quicker. Read the documentation, ask a friend, look at how others do this.
3. Train using the command. Do this until your fingers type it without thinking.
Let"s use an example to show how it works:
1. You find that when you are editing C program files, you often spend time looking for where a function is defined. You currently use the "*" command to search for other places where the function name appears, but end up going through a lot of matches for where the function is used instead of defined. You get the idea that there must be a way to do this faster.
2. Looking through the quick reference you find a remark about jumping to tags. The documentation shows how this can be used to jump to a function definition, just what you were looking for!
3. You experiment a bit with generating a tags file, using the ctags program that comes with Vim. You learn to use the CTRL-] command, and find you save lots of time using it. To make it easier, you add a few lines to your Makefile to automatically generate the tags file.
A couple of things to watch out for when you are using these three steps:
- "I want to get the work done, I don"t have time to look through the documentation to find some new command". If you think like this, you will get stuck in the stone age of computing. Some people use Notepad for everything, and then wonder why other people get their work done in half the time...
- Don"t overdo it. If you always try to find the perfect command for every thing you do, your mind will have no time left to think about the work you were actually doing. Just pick out those actions that take more time than necessary, and train the commands until you don"t need to think about it when using them. Then you can concentrate on the text.
In the following sections there will be suggestions for actions that most people have to deal with. You can use these as inspiration for using the "three basic steps" for your own work.
2. Don"t type it twice
There is a limited set of words we type. And even a limited number of phrases and sentences. Especially in computer programs. Obviously, you don"t want to type the same thing twice.
Very often you will want to change one word into another. If this is to be done in the whole file, you can use the ":s" substitute command. If only a few locations needs changing, a quick method is to use the "*" command to find the next occurrence of the word and use "cw" to change the word. Then type "n" to find the next word and "." to repeat the "cw" command.
The "." command repeats the last change. A change, in this context, is inserting, deleting or replacing text. Being able to repeat this is a very powerful mechanism. If you organize your editing around it, many changes will become a matter of hitting just that "." key. Watch out for making other changes in between, because it will replace the change that you were repeating. Instead you might want to mark the location with the "m" command, continue your repeated change and come back there later.
Some function and variable names can be awkward to type. Can you quickly type "XpmCreatePixmapFromData" without a typo and without looking it up? Vim has a completion mechanism that makes this a whole lot easier. It looks up words in the file you are editing, and also in #include"d files. You can type "XpmCr", then hit CTRL-N and Vim will expand it to "XpmCreatePixmapFromData" for you. Not only does this save quite a bit of typing, it also avoids making a typo and having to fix it later when the compiler gives you an error message.
When you are typing a phrase or sentence multiple times, there is an even quicker approach. Vim has a mechanism to record a macro. You type "qa" to start recording into register "a". Then you type your commands as usual and finally hit "q" again to stop recording. When you want to repeat the recorded commands you type "@a". There are 26 registers available for this.
With recording you can repeat many different actions, not just inserting text. Keep this is mind when you know you are going to repeat something.
One thing to watch out for when recording is that the commands will be played back exactly as you typed them. When moving around you must keep in mind that the text you move over might be different when the command is repeated. Moving four characters right might work for the text where you are recording, but it might need to be five characters where you repeat the commands. It"s often necessary to use commands to move over text objects (words, sentences) or move to a specific character.
When the commands you need to repeat are getting more complicated, typing them right at once is getting more difficult. Instead of recording them, you should then write a script or macro. This is very useful to make templates for parts of your code. For example, a function header. You can make this as clever as you like.
3. Fix it when it"s wrong
It"s normal to make errors while typing. Nobody can avoid it. The trick is to quickly spot and correct them. The editor should be able to help you with this. But you need to tell it what"s wrong and what"s right.
Very often you will make the same mistake again and again. Your fingers just don"t do what you intended. This can be corrected with abbreviations. A few examples:
:abbr Lunix Linux
:abbr accross across
:abbr hte the
The words will be automatically corrected just after you typed them.
The same mechanism can be used to type a long word with just a few characters. Especially useful for words which you find hard to type, and it avoids that you type them wrong. Examples:
:abbr pn pinguin
:abbr MS Mandrake Software
However, these tend to expand to the full word when you don"t want it, which makes it difficult when you really want to insert "MS" in your text. It is best to use short words which don"t have an meaning of their own.
To find errors in your text Vim has a clever highlighting mechanism. This was actually meant to be used to do syntax highlighting of programs, but it can catch and highlight errors as well.
Syntax highlighting shows comments in color. That doesn"t sound like an important feature, but once you start using it you will find that it helps a lot. You can quickly spot text that should be a comment, but isn"t highlighted as such (you probably forgot a comment marker). Or see a line of code highlighted as comment (you forgot to insert a "*/"). These are errors which are hard to spot in a BW file and can waste a lot of time when trying to debug the code.
Unbalanced braces can also be catched by the syntax highlighting. An unbalanced ")" is highlighted with a bright red background. You can use the "%" command to see how they match, and insert a "(" or ")" at the right position.
Other common mistakes are also quickly spotted, for example using "#included &
A more complex example: for English text there is a long list of all words that are used. Any word not in this list could be an error. With a syntax file you can highlight all words that are not in the list. With a few extra macros you can add words to the wordlist, so that they are no longer flagged as an error. This works just as you would expect in a word processor. In Vim it is implemented with scripts and you can further tune it for your own use: for example, to only check the comments in a program for spelling errors.
Part 2: edit more files
-----------------------
4. A file seldom comes alone
People don"t work on one file. Mostly there are many related files, and you edit several after each other, or even several at the same time. You should be able to take advantage of your editor to make working with several files more efficient.
The previously mentioned tag mechanism also works for jumping between files. The usual approach is to generate a tags file for the whole project you are working on. You can then quickly jump between all files in the project to find the definitions of functions, structures, typedefs, etc. The time you save compared with manually searching is tremendous; creating a tags file is the first thing I do when browsing a program.
Another powerful mechanism is to find all occurences of a name in a group of files, using the ":grep" command. Vim makes a list of all matches, and jumps to the first one. The ":cn" command takes you to each next match. This is very useful if you need to change the number of arguments in a function call.
Include files contain useful information. But finding the one that contains the declaration you need to see can take a lot of time. Vim knows about include files, and can search them for a word you are looking for. The most common action is to lookup the prototype of a function. Position the cursor on the name of the function in your file and type "[I": Vim will show a list of all matches for the function name in included files. If you need to see more context, you can directly jump to the declaration. A similar command can be used to check if you did include the right header files.
In Vim you can split the text area in several parts to edit different files. Then you can compare the contents of two or more files and copy/paste text between them. There are many commands to open and close windows, jump between them, temporaraly hide files, etc. Again you will have to use the three basic steps to select the set of commands you want to learn to use.
There are more uses of multiple windows. The preview-tag mechanism is a very good example. This opens a special preview window, while keeping the cursor in the file you are working on. The text in the preview window shows, for example, the function declaration for the function name which is under the cursor. If you move the cursor to another name and leave there for a second, the preview window will show the definition of that name. It could also be the name of a structure or a function which is declared in an include file of your project.
5. Let"s work together
An editor is for editing text. An e-mail program is for sending and receiving messages. An Operating System is for running programs. Etc. Each program has its own task and should be good at it. The power comes from having the programs work together.
A simple example: Select some structured text in a list and sort it: "!sort". The external "sort" command is used to filter the text. Easy, isn"t it? The sorting functionality could be included in the editor. But have a look at "man sort", it has a lot of options. And it"s probably a nifty algorithm that does the sorting. Do you want to include all that in an editor? Also for other filter commands? It would grow _huge_.
It has always been the spirit of Unix to have separate programs that do their job well, and work together to perform a bigger task. Unfortunately, most editors don"t work too well together with other programs - you can"t replace the e-mail editor in Netscape with another one, for example. You end up with a crippled editor. Another tendency is to include all kinds of functionality inside the editor; Emacs is a good example of where this can end up. (Some call it an operating system which can also be used to edit text.)
Vim tries to integrate with other programs, but this is still a struggle. Currently it"s possible to use Vim as the editor in MS-Developer Studio and Sniff. Some e-mail programs that support an external editor, like Mutt, can use Vim. Integration with Sun Workshop is being worked on. Generally this is an area that has to be improved in the near future. Only then will we get a system that"s better than the sum of its parts.
6. Text is structured
You will often work with text that has some kind of structure, but different from what is supported by the available commands. Then you will have to fall back to the "building blocks" of the editor and create your own macros and scripts to work with this text. We are getting to the more complicated stuff here.
One of the simpler things is to speed up the edit-compile-fix cycle. Vim has the ":make" command, which starts your compilation, catches the errors it produces and lets you jump to the error locations to fix the problems. If you use a different compiler, the error messages will not be recognized. Instead of going back to the old "write it down" system, you should adjust the "errorformat" option. This tells Vim what your errors look like and how to get the file name and line number out of them. It works for the complicated gcc error messages, thus you should be able to make it work for almost any compiler.
Sometimes adjusting to a type of file is just a matter of setting a few options or writing a few macros. For example, to jump around manual pages, you can write a macro that grabs the word under the cursor, clears the buffer and then reads the manual page for that word into the buffer. That"s a simple and efficient way to lookup cross references.
Using the three basic steps you can make working with any sort of structured file more effective. Just think about the actions you want to do with the file, find the editor commands that do it and start using them. It"s really as simple as it sounds. You just have to do it.
Part 3: sharpen the saw
-----------------------
7. Make it a habit
Learning to drive a car takes effort. Is that a reason to keep driving your bicycle? No, you realize you need to invest time to learn a skill. Text editing isn"t different. You need to learn new commands and tricks.
On the other hand, you should not try to learn every command an editor offers. That would be a complete waste of time. Most people only need to learn 10 to 20 percent of the commands for their work. But it"s a different set of commands for everybody. It requires that you lean back now and then, and wonder if there is some repetitive task that could be automated. If you do a task only once, and don"t expect having to do it again, don"t try to optimize it. But you probably realize you have been repeating something several times in the last hour. Then search the documentation for a command that can do it quicker. Or write a macro to do it. When it"s a larger task, like lining out a specific sort of text, you could look around in newsgroups or on the internet if somebody already solved it for you.
The essential basic step is the last one. You can think of a repetitive task, find a nice solution for it and after the weekend you forgot how you did it. That doesn"t work. You will have to repeat the solution until your fingers do it automatically. Only then will you reach the efficiency you need. Don"t try to learn too many things at once. But doing a few at the same time will work well. For tricks you don"t use often enough to get them in your fingers, you might want to write them down to be able to look them up later. Anyway, if you keep the goal in view, you will find ways to make your editing more and more effective.
One last remark to remind you of what happens when people ignore all the above: I still see people who spend half their day behind a VDU looking up at their screen, then down at two fingers, then up at the screen, etc. - and then wonder why they get so tired... Type with ten fingers! It"s not just faster, it also is much less tiresome. Using a computer program for one hour each day, it only takes a couple of weeks to learn to touch-type.
Epilogue
The idea for the title comes from the successful book "The 7 habits of highly effective people" by Stephen R. Covey. I recommend it to everyone who wants to solve personal and professional problems (and who doesn"t?). Although some of you will claim it came from the Dilbert book "Seven years of highly defective people" by Scott Adams (also recommended!). See http://www.vim.org/iccf/click1.html and go to "recommended books and CDs".
About the author
Bram Moolenaar is the main author of Vim. He writes the core Vim functionality and selects what code submitted by many others is included. He graduated at the technical university of Delft as a computer technician. Now he mainly works on software, but still knows how to handle a soldering iron. He is founder and treasurer of ICCF Holland, which helps orphans in Uganda. He does free-lance work as a systems architect, but actually spends most time working on Vim.
In all, vim 確實可以提高文本編輯的效率因為對於我這種喜歡vim和emacs的人來說，這種編輯器是最簡單易用的。僅此而已。
1.用vim可以很容易產生滿足感，當你在vim上狂掃鍵盤的時候，旁邊的有些傢伙如果不是被那驚艷的配色給唬到了，就是被你手不離鍵盤的優雅姿勢給迷住了，那一刻可以假裝NB幾秒鐘。
2.vim方便多平台作戰，一個配置文件外加一個插件包，往安裝目錄一丟，順手的編輯器立馬就回來了。
3.幾乎所有Linux發行版本都會自帶vim的祖先vi，在遠程連接的情況下，可以直接使用vi而不是被迫用搓到爆的Nano。
4.用多了vim就養成了敲完一行代碼就按ESC鍵的習慣，不好改。
再說了，代碼敲得飛快，又不代表代碼寫得NB。
再說了，靠這個來裝B，一碰到真正的高手，立馬就被滅了。
我基本沒有使用過vim，因此只針對Emacs的情況來說。其實最初是想針對
為什麼有的程序員極度推崇 Vim 和 Emacs，卻對 IDE 嗤之以鼻？?? - 編程這個問題進行回答的，
但是第一，我並不會對任何IDE或使用IDE的人「嗤之以鼻」，其次我也不認為一個認真的Emacs用戶會對IDE嗤之以鼻，因此就沒法回答這個以「為什麼」開頭的問題了。後來發現我想說的內容針對現在這個問題更合適，所以就發到這裡來啦。
先說說Emacs和IDE比較的問題。Emacs不是一個簡單的文本編輯器，能做到事情遠遠超過IDE。如果只用Emacs來編寫代碼，那麼相當於拿了一把瑞士軍刀卻只用它的主刀片。
說說我自己吧，以前我用Eclipse寫J2EE軟體，後來用Textmate寫RoR軟體；用Word寫文檔，還要一個工具來畫UML圖，導出成圖片後再插入Word文檔。到了Mac上以後改用Pages，流程還是差不多。用Evernote記筆記，用過一些GTD的軟體來做任務管理，嘗試過幾次寫博客，都是在瀏覽器里直接編輯的那種。
目前這些任務都在Emacs里完成啦：
+ RoR的代碼自然在Emacs里完成，前兩個月剛在Emacs里配了Android的開發環境開始學習Android。iOS的軟體還是用xCode，主要因為目前基本不做iOS的開發，只是偶爾看看別人的代碼，做些小修改，因此暫時沒有在Emacs里配開發環境。
+ 技術文檔用org-mode寫，然後導出成PDF；UML圖用PlantUML畫，在org-mode里一氣呵成，再也不用在不同軟體間倒來倒去了。而且可以在文檔里插入帶語法高亮的源代碼，這一點我現在也不知道怎麼在Word或Pages來實現。
+ Evernote的編輯功能實在太弱，又不支持Markdown，因此目前正在逐漸用org-mode來代替。用了deft插件，搜索筆記非常方便。
+ 博客的話用jekyll，自然也是在Emacs里用Markdown寫，然後再發布到github上。這個答案就是在Emacs里寫的，稍後只要做下```git push```就可以發布到我的博客上去了。
+ 任務管理也是用org-mode，接下去準備嘗試把日程管理也從Calendar切換到org-mode來。
所有這些任務都有一個共同點，就是他們都有很多文字輸入和編輯工作。如果象以前那樣要用不同軟體來完成的話，每個軟體的編輯功能多少都有些不同，強弱差別非常大。而統一使用Emacs以後，雖然Emacs的學習曲線有些陡，但是只要學會了以後，在所有這些任務中都能用到。而且因為專註一個軟體，每天大量的時間使用它，很快就很學會和數量使用了。
Emacs有強大的定製功能，可以完全根據個人的習慣、喜好來把它「調教」成個人專屬的功能。而且這種「定製化」的投資對於上述的所有任務都有價值，投資回報超高。
可以說使用Emacs完成的任務越多，用在學習和定製化上的「投資」就越有價值。
使用Emacs的另一個原因是為了貫徹KISS（Keep It Simple）原則。有人可能覺得Emacs超複雜，並且因此而望而卻步，不願意去學習它。但是一旦學會了，用一個Emacs來代替一堆其它軟體的時候，你就會發現生活一下子簡單了很多。不再需要面對很多軟體上面那些根本不會用到的菜單、按鈕，而只專註於完成日常任務所需要的那些最常用的功能上，然後用最有效率的方式去完成它們。因為做伺服器開發沒的選擇！
我覺得手不離鍵盤不是最重要的。重要的是這玩意到處都是又不要錢。雖然折騰，但用熟了還是挺好用的，又顯得高端深度有助於裝B。混技術圈，脫離了新手境界，不整一整這個總有點抬不起頭。
推薦閱讀：
※用mbp文本編輯器寫出來的html在safari和谷歌瀏覽器顯示不同？
※用 Markdown 寫作用什麼文本編輯器？
※Windows 記事本的 ANSI、Unicode、UTF-8 這三種編碼模式有什麼區別？
※為什麼維基百科的編輯器不是所見即所得的？