注：文章来自于Stevey的Blog，英文版权全归原作者。至于中文，列位就当是在公有领域的就好了。
最好帮忙把它译得更好一些，发个diff patch给区区~~
另注：《
effective emacs中文版》已经完成，本页只作为存档和参照用。
Effective Emacs
--
带附注的Effective Emacs中文版
十个提升你Emacs生产力的高招
++
Stevey's Drunken Blog Rants
10 Specific Ways to Improve Your Productivity With Emacs
Emacs is the world's best text editor. It's not just the best for editing program source; it's the best for any kind of text-editing. Mastering Emacs will make you more effective at writing and editing email, documentation drafts, blogs, HTML pages, XML files, and virtually everything else that requires any typing.
--
Emacs是世界上最好的编辑器(真的有很多人这么认为)。不要以为emacs只是在编写程序时很牛X，其实只要你真正精通了emacs，会发现她几乎在所有用到打字的应用(比如写email啦，起草文档啦，写blog啦，写html/xml文件等等等)时都是最牛的。
++
The tips in this little document are geared towards Emacs power-users. You should be familiar with the basics of launching and editing with Emacs, and you should already know the essentials of copying stuff into your .emacs file, and debugging things (or finding a friendly Emacs Wizard) when something goes wrong.
--
本文中所写的招数是面向emacs高级用户（译者看此文时并不是emacs高级用户，同样获益非浅啊）的，你应该熟悉基本的emacs启动编辑操作，你得知道怎么把东东拷到你的.emacs里面，在所拷的东东出现问题时，你得知道怎么调试（或者能找到一个乐于助人的emacs高手也行）。
++
Not all the tips are customizations to Emacs; some of them are changes to your desktop environment to make it work more seamlessly with Emacs.
--
这里所列出的招数并非都是对emacs的定制，有些是对你桌面环境的调节，这些调节可以使桌面环境更好地与emacs无缝连接工作。
++
The key to understanding Emacs is that it's all about efficiency, which includes economy of motion. Any trained musician will tell you that economy of motion is critical to becoming a world-class virtuoso. Any unnecessary motion is wasted energy and yields sloppy results.
--
要想理解emacs的高效，关键是要明白她的所有设计都是出于效率考虑的，这里所说的效率包括“动作的效益”。任何一个老练的音乐家都知道“动作的效益”是成为世界级艺术家的关键一环。在演奏时任何多余的动作都是浪费精力而且会产生不良效果。
++
Using the mouse is almost always the worst possible violation of economy of motion, because you have to pick your hand up and fumble around with it. The mouse is a clumsy instrument, and Emacs gurus consider it a cache miss when they have to resort to using it.
--
使用鼠标基本上可以说是最违背动作效益的行为，因为你得提起你的手...摸着鼠标...摆正方位...可以说鼠标是个极笨重的设备，emacs高手在不得不用一下鼠标的时候，都认为这是一次高速缓冲命中失败（学过微机原理的人可能听得懂这句话吧），大大影响的连贯性和速度。
++
Compared to Emacs Wizards, graphical-IDE users are the equivalent of amateur musicians, pawing at their instrument with a sort of desperation. An IDE has blinking lights and pretty dialogs that you can't interact with properly (see Item 6), and gives newbies a nice comfortable sense of control. But that control is extremely crude, and all serious programmers prefer something that gives them more power.
--
相对于emacs高手，图形化IDE用户就好比业余的音乐家，带着些许郁闷地把玩着自己的乐器。一般IDE都又炫又好看的对话框，让你很难与之交互（这句话面向的听众是emacs高手，看过下面的条款6就会明白他说什么了），但是却给新手一些操控的快感。可是咧~这种操控是相当粗糙的，真正的程序员需要的是能给他们更多操控机能的东东。（所以基本上可以说，emacs对真正的程序员来说是世界上最好的编辑器啦）
++
IDEs also offer Refactoring tools, which are all the rage, because they help you automatically fix your screwed-up code. This is fine, as far as it goes, but I'll tell you a secret: Refactoring tools don't understand English. They won't help you one bit when you're doing something that the tools weren't designed to handle. Refactoring tools are cookie-cutter solutions; Emacs offers you a level of fine-grained control over your environment that makes you the equal of any editing challenge.
--
IDE还具备重构功能，一般什么多人都爱拿这个来吹，因为重构工具可以自动地帮你整理结构不良的代码。没错，在某些程度上来说。但是偶告诉你个秘密喔：重构工具不懂英文耶（所以更不懂中文啦，55）。重构工具一般只能处理一些特定的文本（前面所说的“某种程度”），当她碰上其它编辑工作时，就无能为力啦。重构工具只能解决一小部分问题，而emacs却几乎能在你进行任何一类编辑时提供一系列条理清晰的操控能力。
++
However, as I often point out, this has to be seen to be believed, and even if you believe it, you need to make a serious, lifelong commitment to Emacs in order to master it. Mastering it involves learning Lisp and customizing Emacs to the finest degree imaginable. This simply serves to increase your hunger for more control and more automation, so even if you've mastered Emacs, you're never really finished extending it.
--
然而，正如我常说的，眼见为实，即便你相信，你也得看到实际效果才心甘。那么接下来，你得对emacs做一个严肃的、深远的、长期的承诺，才能真正精通emacs。精通emacs的过程包括学习Lisp、定制emacs使她最符合你的设想，随着这一过程的，你会更加地渴望有更多定制、更多的自动化，所以，哪怕你已经精通了emacs，你对她的定制和扩展也不会停息的。
++
So it's not an editor for the faint of heart, and this blog is targeted at people who have already made the commitment, and want to improve their mastery of this elegant, timeless piece of software.
--
所以，你看明白了吧？emacs可不是一个给懦夫使用的编辑器，这篇博客文章是给那些下了决心、做了承诺并且想要进一步增强他们对这个优雅的*的万古长青的软件的掌握。
++
The rest of you: I think your Eclipse just finished launching, so you can get back to work now.
--
其他的读者或者听众：我想你的Eclipse应该刚好启动完毕了，你可以调头回去忙你自个儿的啦~
++
Item 1: Swap Caps-Lock and Control
--
条款1：把Caps-Lock和Control键互换！
++
On Windows and Mac keyboards, the Ctrl key is awkwardly located in the far lower-left position on the keyboard. The Ctrl key is critical to using Emacs at all times, so you'll never become an Emacs virtuoso unless you move it to an easier position. That position should be on Home Row, so Caps Lock is the best choice. That's the location of the Control key on most Unix workstation keyboards, for precisely that reason.
--
在Windows和苹果Mac键盘上，那个Ctrl键居然被远远地放在左下角，而Ctrl对于emacs的使用却是时时刻刻都很重要的，如果你不把Ctrl放到一个更舒服的位置，你就很难成一个emacs艺术大师了。这位置应该与你的基本手位处于同一行，那么，Caps Lock是最佳选择。在很多unix工作站上，这个位置放的就是Ctrl键，原因同上。
++
To do this on Windows 2000 or XP requires some registry hacking. From the Start menu, choose Run and enter "regedit". In the left-side tree view, click down to:
--
要想在w2000或者XP中实现这个互换，需要修改注册表。从开始菜单中选择“运行”，输入regedit。在左边的树状视图中，找到：
++
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/Keyboard Layout
--
XXXXX不用译了。
++
Click on the KeyboardLayout entry to give it the focus. Make sure it has the focus and not one of its children. Then from the Edit menu, choose New Binary Value, and name it Scancode Map. It should show as type REG_BINARY.
--
点击 KeyboardLayout 项，使之获得焦点。再从“编辑”菜单中选择新建一个二进制值，命名为 "Scancode Map"，它的类型应该显示为 REG_BINARY。
++
Then select the new Scancode Map entry you just created, and from the Edit menu (whose contents should have changed), choose Modify Binary Data. In the dialog box called Edit Binary Value, enter the following data:
0000: 00 00 00 00 00 00 00 00
0008: 03 00 00 00 3A 00 1D 00
0010: 1D 00 3A 00 00 00 00 00
--
然后选择这个新建的"Scancode Map"值项，用“编辑”菜单中选择修改二进制值，在二进制编辑对话框中，输入下列数据：
0000: 00 00 00 00 00 00 00 00
0008: 03 00 00 00 3A 00 1D 00
0010: 1D 00 3A 00 00 00 00 00
++
Select OK to close the dialog, then exit the Registry Editor. The caps and ctrl keys should be swapped as soon as you log out and back in again. It may require a reboot.
--
选择OK关闭对话框，退出注册表编辑器，注销后重登入，你的caps和ctrl键应该就互换成功了。也可能要重启一次。
++
On Linux in X-Windows, you use the xmodmap utility. Create a file in your home directory called .xmodmap if it doesn't already exist, and put in the following lines:
!
! Swap Caps_Lock and Control_L
!
remove Lock = Caps_Lock
remove Control = Control_L
keysym Control_L = Caps_Lock
keysym Caps_Lock = Control_L
add Lock = Caps_Lock
add Control = Control_L
Save it, and add the line xmodmap ~/.xmodmap into your ~/.bash_profile.
--
在linux的X-Window中，可以使用xmodmap工具。在你的主目录新建一个名字为.xmodmap的文件，如果已经存在则只需修改。向该文件加入下列内容：
!
! Swap Caps_Lock and Control_L
!
remove Lock = Caps_Lock
remove Control = Control_L
keysym Control_L = Caps_Lock
keysym Caps_Lock = Control_L
add Lock = Caps_Lock
add Control = Control_L
保存，再向你的 ~/.bash_profile 文件加入一行：
xmodmap ~/.xmodmap
++
On Mac OS X (Panther and Jaguar) you need to install a modified keyboard driver, which is a little scary, but it seems to work. Here's a discussion of the driver. Alternately, if you're not using a Mac laptop, there appears to be an XML file you can edit as root; it's described here.
--
This URL has some information on doing it on other systems.
在Mac OS X（Panther或Jaguar）中，你得安装一个修改过的键盘驱动，这说来有些吓人，但是很有效。
这儿有个关于驱动的讨论：
http://www.macosxhints.com/article.php?story=20031102032521826
如果你用的不是Mac笔记本，好像有一个XML文件可以编辑来实现，可以参考这儿：
http://www.eecs.wsu.edu/%7Eschneidj/mac-os-x-10.3.html#swap
下面的URL有一条关于在其它系统上实现的信息：
http://www.manicai.net/comp/swap-caps-ctrl.html
++
Item 2: Invoke M-x without the Alt key
--
条款2：不用Alt来调用M-x
++
Alt-x is one of the most frequently typed Emacs key combos, and it involves scrunching your left hand up. Anything you're going to do thousands of times should be streamlined, so you want to be able to start a M-x sequence with the Ctrl key (once you've completed Item 1!)
--
Alt-x是最常用的emacs组合键，每次使用时你都得把左手蜷起来。任何一个你要做几千次的动作最好应该是流线型的，所以你最好希望可以用Ctrl键来调用M-x。（要想用Ctrl舒服，你得选把条款1完成了）
++
There's another very important reason to get in the habit of using a Ctrl sequence: the Alt key is unreliable and nonstandard across platforms. In particular, when you're logged in to a remote host via telnet or ssh, Alt-x may or may not work, depending on the system type and the terminal configuration. Rather than mess with the headache of learning to configure every system you work on to know about the Alt key, it's easier to use a key sequence that always works.
--
要养成使用Ctrl键习惯的另一个重要原因是:Alt键并不可靠也并不是跨平台的标准键（译注：好羡慕作者能接触那么多BT的机型啊）。尤其是当你通过telnet或者ssh远程序登录时，在一些系统的设置或者终端设置下，alt-x可能都不能使用。与其为不同的系统设置而头痛，还不如直接就不使用alt键，使用一个任何时候都有效的组合键相对来说更加容易且方便。
++
The key sequence I use is Ctrl-x Ctrl-m. Note that when you invoke a 2-key sequence with the same modifier key, you can just hold down the modifier key, then press the 2 keys. So with this key sequence, invoking M-x involves pressing and holding Ctrl, typing x, then typing m.
--
我选用的组合键序列是Ctrl-x Ctrl-m。请注意，当你调用一个2键序列，而这两个组合键都使用相同的转义键时，你只需按住转义键（这里指Ctrl），再按其它两个键即可（这里指x和m）。所以现在调用M-x的方法是：按住Ctrl，按x，按m，松开Ctrl。
++
To enable the Ctrl-x Ctrl-m sequence add the following lines to your .emacs file:
(global-set-key "/C-x/C-m" 'execute-extended-command)
(global-set-key "/C-c/C-m" 'execute-extended-command)
--
将下面的lisp表达式加到你的.emacs文件中，就可以启用Ctrl-x Ctrl-m了：
(global-set-key "/C-x/C-m" 'execute-extended-command)
(global-set-key "/C-c/C-m" 'execute-extended-command)
++
I add the second line so that Ctrl-c Ctrl-m will also invoke it, which makes the key sequence even more forgiving. If I miss Ctrl-x and hit Ctrl-c accidentally, it still works. Neither of these key sequences is bound by default in Emacs, so you're not biffing any other useful shortcuts by doing this.
--
我另加了一行设定Ctrl-c Ctrl-m也调用同一命令，使得这个按键组合更能容错一些。如果偶不小心把Ctrl-x按成Ctrl-c，仍然能够成功调用。这两个按键都没有默认的emacs绑定，所以你的设置不会影响到其实的快捷键。
++
You should practice this key sequence until you get used to it, and then you'll almost never need to use Alt-x again. (You'll still use the Alt key for other commands, which I'll cover later.)
--
你应该把这个按键序列练到习惯为止，到时你差不多都不想再用alt-x了。（当然，你还会用到alt键来做其它的事，一会儿就告诉你）
++
Incidentally, if you want to fine-tune this tip to extraordinary levels, then you probably don't want to use your ring-finger for typing the x-key when you hit Ctrl-x. I use my left index finger, since I'm used to it that way, but you're probably better off using your left middle finger. The reason is that your hand isn't technically on home row when your left pinkie is jammed down on the Caps-Lock key that you've turned into Ctrl. The point is to use whatever requires the least amount of stretching, followed by the least amount of finger motion. You should experiment until you find what's most comfortable for you.
--
顺便说一下，如果你想把这招发挥到极致，那在你按Ctrl-x最好不要用你的无名指来敲x键。这时我会用左手的食指的敲，因为觉得这样比较习惯，但是你可能会觉得用左手中指会更好一些。这是因为当你用小指去按那个变成Ctrl的Caps-Lock时，你的手并不处于键盘的基本方位。关键是要使用尽可能少的肢体伸缩，尽可能少的手指动作。你可以实验出你自己觉得最舒服的方式来。
++
Item 3: Prefer backward-kill-word over Backspace
--
使用 backward-kill-word (向后删一词)而不是 Backspace（向后删一字）
++
Emacs Wizards try to avoid hitting the backspace key, because it's just remote enough from home-row to be annoying. We make typing mistakes all the time, but if you type faster than about 50 wpm, it's more economical to kill the entire word and re-type it than to painstakingly backspace to your error.
--
emacs高手一般都尽量避免使用backspace键，因为它离手的基本方位太远了。如果你经常打错字，但是你的速度又很快，一分钟打50个词以上的话，把整个词删掉重打可比勤勤恳恳地用backspace倒删到你打错的地方再从一半打起要经济实惠得多。
++
Here's what you add to your .emacs file:
(global-set-key "/C-w" 'backward-kill-word)
(global-set-key "/C-x/C-k" 'kill-region)
(global-set-key "/C-c/C-k" 'kill-region)
--
加入下面的几行到你的.emacs文件中：
(global-set-key "/C-w" 'backward-kill-word)
(global-set-key "/C-x/C-k" 'kill-region)
(global-set-key "/C-c/C-k" 'kill-region)
++
Note that because Ctrl-w was already bound to kill-region, a very important command, you need to re-bind something else to kill-region. I chose Ctrl-x Ctrl-k (and its sloppiness-forgiving companion, Ctrl-c Ctrl-k), primarily because that's the way they did it at my old company, which was filled with wise Emacs Wizards who taught me a lot of what I know. Rebinding Ctrl-x Ctrl-k means it's no longer available for edit-kbd-macro, but you'll use that infrequently enough that it's not something you'll miss having a shortcut for.
--
请注意ctrl-w已经有一个默认绑定kill-region了，这是个相当重要的命令，所以你得把它重新绑定到其它按键序列中去。我用的是Ctrl-x Ctrl-k(然后再加一个容错版的Ctrl-c Ctrl-k)。这样用主要是因为我在以前工作的公司，一个很牛X的emacs高手这么帮偶设的，现在我会的很多emacs技术都是当初这个高手教偶的。重绑定Ctrl-x Ctrl-k意味着你没有了edit-kbd-macro的快捷键，但是这个键你真的不会经常去用，所以不会觉得丢了什么东东的。
++
As an added benefit, many Unix command shells provide Emacs-like command-line editing keys, and Ctrl-w is usually the default binding for backward-kill-word. So your usage will be consistent in shells.
--
这样做还有一个额外的好处：很多Unix命令行shell都提供类似emacs的命令行编辑按键，而Ctrl-W一般都是backward-kill-word的默认绑定。这样的话，你的习惯就和很多shell一致了。
++
The faster you type, the more valuable this tip becomes. You'll gradually develop a "feel" for the fastest way to back up and correct various kinds of typing mistakes. In general, here's how my fingers decide these days:
--
你打字越快，这招就越升值。慢慢地你对如何最快更改各种打字错误会培养出一种最适合你自己的感觉。我的手感一般是这样的：
++
1. If I've mis-typed a character or two in a fairly long word, and my cursor is still located right after the typo, then I'll use the backspace key.
--
1.如果我打错一两个字符，而此时我的光标刚好就在错误的旁边，我就用backspace键。
++
2. If the typo is somewhere in the last 15 to 20 characters or so, then I'll usually backward-kill-word to kill backward over the typo, and re-type the words.
--
2.如果错误字符在光标前面15到20个字符左右的地方，那我一般就使用Ctrl-W直接杀回去，然后重新打出这些词来。
++
3. If the typo is further back than that, but still on the same line, I'll use Alt-B to skip the cursor back to the word with the typo, and Ctrl-b to move it within the word to get to the typo.
--
如果错误的字还在更远处，那偶就用alt-b跳回到错词后面，再做ctrl-b定位到错误的字符处理进行更正。
++
For mistakes further away, I'll use Fast Navigation to get there: Item 4 covers at least part of this technique.
--
对于比之更远的错误，我会使用快速导航来回到那个位置。条款4讲到一部分这个技术。
++
One thing you'll need to be very careful of if you use Ctrl-w for backward-kill-word: Ctrl-w is hardwired to kill the window in many Windows applications. Do not pass go, do not collect $200, and in browser windows, do not save the contents of your form fields. That means if you're typing out something into an HTML form field, and you accidentally make a typo and hit Ctrl-w, kapow! All your work will be lost instantly for you by Good Ole Microsoft Windows. I know of no way to override this horrid behavior. If you know, please tell me.
--
使用ctrl-w绑定backward-kill-word时有件事情你可得小心了：Ctrl-w在很多windows程序中是强行绑定到“关闭窗口”这一操作上的。这一动作没得后悔，在浏览器窗口中，它也不会保存你填写过的表单。也就是说，如果你正在为一个网页填写表单，然后你忽地想用ctrl-w来更正一个错误，咔嘣！--完咧~在你那好用的OLE版M$ windows上，你的所有工作都白费了。目前我还不知道怎么覆盖掉这个可怕的行为，如果你知道怎么做，麻烦你考虑我一下。
++
Item 4: Use incremental search for Navigation
--
条款4：使用递增式搜索来进行快速导航
++
Moving the cursor around efficiently is one of the keys to becoming an Emacs Wizard. IDE users spend most of their time fumbling around with the mouse. They wouldn't dream of doing it any other way, but they don't realize how inefficient their motions are. In the hands of a Master, Emacs becomes the most powerful and efficient text-editing tool on the planet, in large part because it allows you to do almost everything without using the mouse.
--
知道如何高效地移动光标是成为emacs高手的关键。IDE用户把他们大部份的时间花在摸索鼠标上了，根本没有想过如何用其它方法来实现光标导航，却不知道自己的方法是多么的低效。在一个高手的手中，emacs是世界上最高效的文本编辑工具，主要是因为她可以让你不用鼠标做到几乎所有的事情。
++
Emacs Wizards always have their Emacs sessions as tall as possible, filling the screen vertically, because vertical screen space is such a premium when you're viewing a document. When you can view a fair number of lines of text on screen at once, using incremental search is often much faster than any other way of precisely positioning the cursor.
--
emacs高手总是设法让他们的会话窗口越高越好，最好是能垂直地填满整个屏幕--因为垂直的屏幕空间在你查看一个文档时可以说是最宝贵的空间了。当你使用屏幕空间一次性查看多行文本时，使用递增式搜索一般比使用鼠标直接定位要快得多。
++
Get in the habit of using Ctrl-r (isearch-backward) and Ctrl-s (isearch-forward) for moving around in the document. Whenever you need to jump the cursor backward or forward more than about 5 lines, and you can see the target location, you should be using i-search.
--
养成使用ctrl-r(向前递增式搜索)和ctrl-s(向后递增式搜索)来在文档中进行移动的习惯。当你要向前或者向后移动5行左右，而且你又看得到移动的目的地时，你应该使用递增式搜索。
++
To do it effectively, you don't necessarily need to search for the exact word where you want to put the cursor. Let your eye defocus slightly and take in the whole paragraph or region around the target point, and choose a word that looks reasonably unique or easy to type. Then i-search for it to navigate to it. You may need to hit Ctrl-r or Ctrl-s repeatedly if your anchor word turns out not to be unique. But Emacs will highlight all the matches, so if there are more than a couple of them, Ctrl-g out of the search and choose another anchor word.
--
要想高效地做到这一点，你并不需要搜索你光标目的地处的整个单词。让你的目光掠过目标点周围的一行或者一段话，选择一个看起来唯一性比较强而且比较好敲的单词，然后递增地搜过去。如果你选单词不是那么的唯一，那可能要按两三次crtl-r或者ctrl-s。但是放心，emacs会把已匹配的单词高亮显示，如果你看到匹配的东东太多了，按一下ctrl-g，然后重找一个词来递增导航。
++
It's difficult to overemphasize how powerful this technique is, once you've mastered it. Mastering it simply requires that you do it repeatedly until your fingers do it "automatically". Emacs eventually becomes like an extension of your body, and you'll be performing hundreds of different keystrokes and mini-techniques like this one without thinking about them. It's comparable to the hundreds of subtle techniques you acquire for driving a car well.
--
一旦你掌握了它，再怎么强调这一招数的强大都不会过份的。你必须不断地重复直到你的手“自动地”去这样按才能算是真正掌握这一招。这时，emacs就好像变成你身体的延伸一样，成为你身体的一部分，你可以想都不用想就把这些微妙的按键敲出来。这类似于你学车时最终掌握的一些微妙的本能反应。
++
Item 5: Use Temp Buffers
--
条款5：使临时Buffer
++
One of the most powerful things about Emacs is its ability to swiftly generate a new buffer that isn't associated with a file or process. Once you get used to using this technique, you'll sorely miss the functionality in other editors and applications.
--
emacs最强大的功能之一就是她可以迅捷地生成一个不与任何一个文件关联的buffer。一旦你习惯了使用这一技术，你就对明显地感觉到其它编辑器这一功能性的不足。
++
To create a temp buffer, just switch to it! Ctrl-x b invokes the command switch-to-buffer, and you just type in adsflj or whatever comes out of drumming on the keyboard. Instantly you've got yourself a scratchpad, where you can take notes, dump temporary results, or use it in any way that's convenient for the problem at hand.
--
要想建一个临时buffer，很简单，切换过去就是了！Ctrl-x b调用命令switch-to-buffer，然后你就瞎按一通adsflj。马上地你就来到一个草稿本上，你可以在上面做笔记，把临时结果导过来，或者用来做任何对你手头问题有帮助的事。
++
If you plan on keeping multiple temp buffers around, you might give them more memorable names, such as foo, bar, baz, and buh.
--
如果你打算维护多个临时buffer，你则应该给它们起些好记点的名字，比如：foo, bar, baz, buh...等等
++
If you want to see your temp buffer side-by-side with another buffer, you can split the screen horizontally or vertically. See Item 6.
--
如果你打算边靠边地比对两个buffer，你可把emacs屏幕水平地分割一下。（条款6会讲到）
++
Because your temp buffers aren't associated with a file, you can kill them just as quickly as you created them using Ctrl-x k, the kill-buffer command.
--
由于你的临时buffer并不与任何一个文件关联，你杀它们就跟创建它们一样方便，用ctrl-k，也就是kill-buffer命令。
++
If you decide you want to save the contents of a temp buffer somewhere, just switch to the buffer and Ctrl-x Ctrl-w to invoke the write-file command. It will prompt you for a filename, and after saving, you can kill the buffer safely and revisit the file contents later.
--
如果你打算保存临时buffer的内容了，也很简单，使用Ctrl-x Ctrl-w调用write-file命令。她会提示你输入一个文件名。保存文件后，你可以杀掉这个buffer（译注：区区真的很喜欢用杀这个词来替代关闭这一说法~），并可以随时通过打开文件重新访问它的内容。
++
Item 6: Master the buffer and window commands
--
条款6：精通有关buffer(缓冲区)和window(视窗)的命令
++
You'll frequently want to do some editing task and have multiple windows open. Emacs uses slightly different terminology from most other applications. A "buffer" is a logical space that contains some text, possibly tied to a file or process. A "window" is a visible region on screen displaying exactly one buffer (or part of it). A "frame" is what you call a "window" in OS-lingo: a standalone window with its own title bar and so on.
--
你会经常做一些需要打开多个视窗的编辑工作的。emacs使用一套与其它应用程序有些许不同的术语。一个buffer是指一个包含文本的逻辑空间，这个空间有可能会与一个进程或者文件关联；一个window是屏幕上显示着一个buffer（或者这个buffer的一部分内容）的可见区域。一个frame(窗框)则是一个你在操作系统说法里面管它叫window（窗体）的东西：一个独立的包含标题栏或者是类似东西的窗体。
++
The most important commands to master are:
* Ctrl-x 2: split-window-vertically -- splits your current window into two equal-height windows showing the same buffer (until you change one of them to show something else.)
* Ctrl-x 3: split-window-horizontally -- most people don't use this as often, but it's occasionally useful. Splits the window into a left-side and a right-side.
* Ctrl-x +: balance-windows -- makes all visible windows approximately equal height. This is useful if you've just done Ctrl-x 2 twice in a row, because you'll have two 1/4-height windows and one 1/2-height window. Ctrl-x + makes them all the same height.
* Ctrl-x o: other-window -- moves the cursor into the next window in the window list, which usually means moving it to the window below the current one, or wrapping back up to the top.
* Ctrl-x 1: delete-other-windows -- makes the currently focused window fill the entire frame; the others go away. Note that the buffers they were visiting stay around in the buffer-list, so it's always perfectly safe to execute this command.
* Ctrl-x Ctrl-b: list-buffers -- shows a list of all the buffers you have open, in a nicely formatted buffer called "*Buffer List*". This buffer's mode has many convenience keys for manipulating the buffer list. For instance, typing "d" while the cursor is on one of the entries will flag that buffer for deletion, "x" will kill the buffer, and so on. Use M-x describe-bindings to view all the Buffer-menu key bindings.
--
下面是几个需要重点掌握的命令：
* ctrl-x 2: split-window-vertically -- 把你的当前window切成上下两个等高并且显示同一buffer的window（在你改变其中一个让它显示其它buffer之前）
* ctrl-x 3: split-window-horizontally -- 很多人并不常用这个，但有时它非常有用喔。--把当前window切成左右两个等宽window。
* ctrl-x +: balance-windows -- 让所有可见的window近似等高。如果你刚用ctrl-x 2两次，那你就有两个1/4高的window和一个1/2高的，使用这招可以让这三个window变得等高。
* ctrl-x o: other-window --把光标移动到window列表的下一个window当中去，一般会把光标移到window下面一个window，或者回滚到最顶的window。
* ctrl-x 1: delete-other-window -- 让当前光标所在的window填满整个frame；其它的window都会消失。请注意buffer是由buffer-list的维护的，所以无论什么时候运行这个命令都是安全的啦。
++
Dialog Boxes: The Root of All Evil
--
对话框：所有罪恶的根源
++
Emacs is an incredibly powerful editor, but a few design choices in particular really stand out as being the biggest individual contributors. One of them is the fact that Emacs has no dialog boxes. This was actually a requirement in order to give Emacs its full functionality while running in a text-only terminal window. But by happy accident, it's also one of the key features that helps make Emacs so insanely powerful.
--
有几个软件设计决择是促使emacs成为一个无比强大的编辑器的主要原因。其中一个就是：emacs没有对话框！当然，这也是emacs在一个只能显示文本的终端窗口也能提供完备功能的一个前提条件。但是巧就巧在，这正是使emacs暴走般强大的一个关键的特性。
++
Dialog boxes suck. For starters, they always have focus issues, and often cause poorly-designed applications to lock up or fail to refresh while the dialog is open. And dialog boxes never seem to play along with any customizations to your video mode. For example, if you set up a dual-monitor display using 2 cards, the application dialogs in Windows will tend to pop up in the wrong window, making the whole experience a really annoying pain in the ass.
--
对话框很废！对新手，经常会有焦点不明的问题，很多设计不好的程序还会因为对话框而自锁在刷新线程里面。对话框在你定制的视频模式下面从来就不会表现得很好。比如说吧，如果你设置了用双显卡设置了双头显示，在windows中的应用程序对话框老是会从错误的一个窗口中弹出来，这种事情跟生痔疮似的让人难受无比。
++
Dialogs sometimes come up in unpredictable places even on single-monitor machines. And even in well-designed applications like the Microsoft Office suite, modal dialogs can still wind up buried behind a bunch of other windows on your screen, which makes the application seem like it's totally unresponsive until you find the rogue dialog and bring it to the front.
--
在一个单显示器的机器上，对话框有时会在出现在你意料之外的地方。哪怕是像Microsoft Office这样设计精良软件程序，模式对话框也会从一堆被隐盖的窗口中的某一个里弹出来，这会让整程序看上去完全没有回应，在你找到那个无赖对话框并把它置顶之前，程序就像死掉一样。
++
For some strange reason, dialog boxes are often non-resizable. It's the opposite for application windows: those are almost always resizable, and app designers usually take great pains to make the UI rearrange to fill the space nicely if you resize the window. But with dialogs, the default seems to be non-resizable, possibly because on most OSes, dialogs are a screwed-up hack that was added on long after the window manager was designed without dialogs in mind. (Guess how I know this.) Hell, they're even a mess in Java Swing.
--
由于一些很奇怪的原因，对话框一般都大小不变的。这与应用程序窗体正好相反：它们几乎都是可改变大小的，也正因为如此，很多用户界面设计师要花好大的功夫来保证各种用户界面元素在窗体改变时能安排恰当的位置和尺寸。但是在默认情况下，大部分的对话框都是尺寸固定的--也许这是因为对话框根本就是窗口管理器设计完成之后再草草加入的补丁功能，而窗口管理器的设计压根儿就没把对话框考虑在内(猜猜俺是怎么知道这个的吧~~)。TMD，甚至在Java Swing中，对话框也是一团糟。
++
And don't get me started on the buttons. We've had dialog boxes in GUIs for at least 25 years, but people still can't agree on a standard set of buttons for them, or even a standard place to put the buttons. Some dialogs put them in the title bar, some on the bottom, some on the right side. And it's rarely 100% clear what will happen if you use the Window controls in the title bar to close a dialog, bypassing its button choices. The whole experience is a giant crap sandwich, and everyone knows it intuitively, but it's just how everyone assumes things have to be.
--
还有，你别跟俺提按钮的事儿，一提这个就来气儿。对话框在GUI世界里都有至少25年历史了，但是对话框上该有些什么按钮都还没有一个统一的标准--甚至连按钮应该放在哪儿都各有各的说法。有些对话框把按钮放在标题栏里、有些放在底下、有些左边、有些还在右边。当你想用标题栏中的控件来关闭对话框时，由于不同的GUI设计，很难100%保证它真的会按你想的那样去做。谁都知道这样很违背直觉，但是大伙儿又只能听之任之。
++
But the problem with dialog boxes goes even deeper than the focus, sizing and positioning problems. Dialogs are never, ever full peers of the rest of the application UI. If you define any keyboard macros (not just in Emacs -- in any app, such as Excel or Word), they won't work in dialog boxes. If the dialog has a scrollable widget, you have no options for navigating other than by using the scrollbar.
--
对话框的问题远不止于“输入焦点”、“尺寸变更”、“控件定位”。哪怕你把对话框做得和主程序的UI一模一样，对话框也无法具备主UI的功能。比如你定义(或者录制)了键盘输入的宏(不光是emacs有macro--其它程序如Excel或Word都有)，那么这些宏在对话框中是无效的。如果对话框有一个可以卷动的控件，那可能你除了用卷动条之外再没其它办法可以卷页了(在emacs里的话，哪都能用C-v M-v)。
++
To illustrate, fire up Internet Explorer and choose Internet Options from the Tools menu. Go to the Advanced tab. There they are: all your pathetic global customization options for IE. If you want to find a particular option, you have to scroll slowly, looking for it. You can't use Edit/Find because the dialog is, of course, modal. And the dialog is, of course, also non-resizable. Most dialogs are like this.
--
形象一点来说就是，现在你打开IE，选择Internet选项，进入‘高级’标签页。就在这儿了：你所有的全局自定义IE的选项都可怜巴巴地列在这儿。如果你想找到其中一个特定的选项，那就得小心翼翼地卷动，放大眼睛地看，再用鼠标点。休想用‘编辑/查找’，这当然得是一个模式的，尺寸固定的对话框。基本上，对话框都这样。
++
Buffers to the Rescue
--
救星：Buffer
++
In Emacs, all output goes into buffers, and all buffers are first-class citizens. All your favorite navigation shortcuts are available in all buffers, including i-search. You can select and copy text out of any buffer, and there is no such thing as a "modal" buffer, so you can keep the output around as long as you like, while continuing to work in other windows. It doesn't even have to be visible; the "dialog" output stays in the buffer list until you dismiss it.
--
在Emacs中，所有的输入都写入buffer里，而buffer是Emacs的‘一等公民’。所有你最喜爱的导航快捷键，包括增量搜索，在任何buffer中都是可用的。你可以在任意buffer中选择和拷贝文本，在Emacs中没有什么‘模式的buffer’，所以你可以在保留任何buffer的内容的同时在其它window中工作，这些buffers不一定是可见的--这种‘对话框’的内容会一直保留在buffer列表中，直到你亲自删除它。
++
There is nothing else quite like the Emacs buffer experience in all of application-dom. Once you realize how consistent and powerful this model is, all other applications become slightly distasteful, because you know their UI is just getting in your way.
--
在其它的程序中你很难找到像Emacs的buffer系统这样的体验。一旦你领会到这种模型是多么的强大和一致，你使用其它程序时就会觉得有点不爽了--因为老会觉得它们的UI很碍事儿。
++
Once you learn to master those buffers and windows, and sling them around with ease, you'll be on your way to Emacs Wizardhood.
--
精通buffer和window，并且对它们的操控游刃有余的时候，你就步上Emacs的大师之路了。
++
Item 7: Lose the UI
--
条款7：丢弃UI
++
You don't need a menu bar. It's just a crutch placed there for disoriented newbies. You also don't need a toolbar with big happy icons, nor do you need a scrollbar. All of these things are for losers, and they are just taking up precious screen real-estate. Turn them all off with the following code in your .emacs file:
--
你不需要菜单栏，菜单栏只不过是给那些找不着北的新手用的拐杖而已。同样，你也不需要有大按钮的工具栏，不需要卷动条--这些东东都是给失败者的，而它们却占用了宝贵的屏幕空间。还是在.emacs中用下面的代码把它们全关了吧。
++
(if (fboundp 'scroll-bar-mode) (scroll-bar-mode -1))
(if (fboundp 'tool-bar-mode) (tool-bar-mode -1))
(if (fboundp 'menu-bar-mode) (menu-bar-mode -1))
You won't miss any of it. We'll cover how to find your way around in the next tip.
--
关掉这些东西，你不会丢失什么功能的，在下一个条款中我将谈到具体的高效作法。
++
(Notes added Jan 2nd, 2006) I recently saw a comment from a person who hated this entire essay because of tip #7. The person expressed a great deal of disgruntlement, evidently being quite attached to his or her mouse and menus, and took affront to being called a "disoriented newbie". The person went on to claim that using the mouse has been proven "faster" by countless studies. So I figure I should elaborate a bit. The remainder of this tip is All New, thanks to that disgruntled reader's blog.
--
(2006/01/02加入的注解)最近看到一个人回复，此君因为条款7而对本文全篇不爽。此外，他
++
First I should observe that I often wish Emacs had a richer rendering engine, enabling it to do GUI and graphics on par with other desktop applications. It may never happen; my blog-rant The Emacs Problem talks about this a bit. But I'd love to see it. I bring this up as evidence that I'm not a thoughtless anti-GUI person.
Scrollbar: optional
I usually turn off the scrollbar in Emacs because there are keystrokes that can achieve the same effect. However, scrollbars have the advantage of providing analog feedback as to how far into the buffer you are, and how long it is. The digital feedback provided by the %-indicator in the status area isn't as easy to read -- countless studies have proven that. It's why the U.S. Navy uses analog gauges in their reactor plants, for instance. It's too easy to glance at a digital (i.e. numeric) gauge and misread it.
So I have no real problem with scrollbars, if you're more comfortable with them. Just be aware that they'll tempt you to reach for the mouse, but for certain operations (e.g. jumping to the beginning or end of the buffer), it's much faster to use the keyboard. No user studies are necessary to justify this claim, either. Some simple timing experiments should convince even the most skeptical reader.
Keyboard wins for navigation
Let's say we want to put a row of 80 hyphens at the very beginning and very end of a long buffer, and you're currently in the middle of the buffer. It's slightly contrived, but I've done it when putting together a "cut here" excerpt containing the buffer contents. Using the keyboard, I'm done in under 3 seconds, ready to move on to the next task. The key sequence I had to type was "C-x t C-u 8 0 - RET C-x e C-u 8 0 -", or 13 key presses.
There's simply no way you could do this reliably in 3 seconds with the mouse, since you'd have to make 2 complete round-trips to the mouse, to grab the scroll button (aka "thumb" or "elevator") and drag it to the top or bottom, then return to the keyboard to type out the text. A quick trial took me close to 15 seconds. Scrolling to the top does NOT move the cursor to the first character, so you also have to carefully position the cursor there.
Sure, you could practice it a bit, and maybe get it down to 10 seconds, but why bother? If you're going to do that exact operation frequently, you should write a macro for it.
Mouse use case #1 of 1: region selections
There are clearly some operations that will be faster with the mouse. Interacting with your window system outside Emacs is usually faster with the mouse, as is interacting with other applications that don't have Emacs-like keyboard navigation. But inside Emacs, I can only think of one thing that's faster with the mouse: region selection, particularly if you're selecting a rectangle.
Sometimes region selection with the keyboard is faster: for instance, setting the mark and holding down Ctrl-n to start selecting lines, or Ctrl-f to grow the selection by a character at a time. But the keyboard repeat rate, which is set in hardware, can feel annoyingly slow. I can see about 100 lines of text in a buffer window on my display, and selecting those lines with the keyboard (assuming I'm starting with the point somewhere in the middle) takes about 5 seconds. Selecting them with the mouse and returning to home row takes about 4 seconds. So when I just need to select lines in the visible area, the mouse usually isn't worth it.
However, if I need to select a region that's taller than my window size (by drag-selecting), or I need to select a region whose beginning and end columns both fall mid-line somewhere, then the mouse is the most reliably fast approach, and I'll use it happily.
Using the mouse for selections isn't turning off the UI, though, so it's only slightly related to this tip. The point is that I actually do timing experiments like this once in a while. My opinions about the GUI in Emacs are backed by 20 years of this kind of experimentation. And I'm recommending that you turn off the menus. Really.
Menus: lose 'em!
Menus are fine for exploration, for learning more about Emacs's capabilities. Unfortunately they can easily lull you into thinking the cover everything Emacs can do. However, many Emacs packages don't have any menu support -- it's only the super-meticulous package designer who goes to the effort of adding menu support. So if you're using the menus for browsing and exploring Emacs, you're missing out on a lot of functionality.
Another problem with menus is related to my rant about dialogs earlier: they don't scale well. If you want to provide the user with 1500 choices, putting them in a menu will tax the windowing system to the limits of its ability. Doing it in an Emacs buffer is trivial, and gives you a lot more real-estate in which to do nice layouts and groupings of the choices. Type M-x list-colors-display or M-x list-faces-display to see some examples of what I mean.
Another (huge) problem with menus is that they're not searchable, and they don't do auto-completion. You can easily find yourself digging way down some submenu heirarchy, thinking you're getting close, but you're actually barking down the wrong tree. They're nowhere near as flexible an exploration mechanism as searchable help -- this is every bit as true in Microsoft applications as it is in Emacs.
And finally, once you've memorized a menu action, you always have to go back to the menu (and possibly submenus) to perform it. The more often you do the action, the more time you've wasted compared to using a keyboard shortcut.
So I think Emacs menus are no good. They don't show you everything Emacs can do; they don't suggest alternatives when you can't find what you want; they're not capable of scaling to thousands of choices (so they're not a very good general-purpose UI mechanism, compared to something like a tree view), and they're slow to access even when you know how to use them.
In short: turn off those menus! And as for big shiny buttons, well, gosh. Anything important enough for a button is important enough for a fast keyboard shortcut.
Item 8: Learn the most important help functions
--
条款8：掌握最重要的帮助功能
++
To find out all the keyboard shortcuts that are defined for the current buffer, type M-x describe-bindings. It shows you a list of keys and the commands that they're mapped to.
If you move the cursor to one of the commands in this list, and hit Enter, it'll show you the Help for that command.
To find out what a particular key does, use M-x describe-key, and then type the key sequence you're interested in. It goes directly to the Help for that key, if the key is currently bound to a command.
If you're interested in finding a command, and you have a guess as to the name but you aren't sure exactly what it's called, use M-x apropos, followed by a regular expression (see Item 9) to use for matching command names. All Emacs commands (as well as functions variables, and property lists) are kept in global tables that can be searched with M-x apropos.
If, for instance, you're looking for a function that sends a buffer all the way to the back of the list, you could type M-x apropos-command buffer, which shows about 200 available commands with the word "buffer" in the command name. Near the top is a command, bury-buffer, whose documentation says:
bury-buffer M-x bury-buffer RET Command: Put BUFFER at the end of the list of all buffers.
Et voila. Just the command you were looking for. You can easily winnow the search through large lists by specifying a more restrictive regexp.
Perhaps the most important Help function is M-x info, which brings up Emacs's interactive, menu-driven Info engine. You should learn to use Info. It has thousands of pages of documentation, and it's hyperlinked (in its own custom way that predates the Web, unfortunately), so it's much easier to navigate than, say, man pages. Once you've mastered the navigation keys in Info, it's faster than navigating HTML help with a browser, even for local static files, in part because of Info's ability to perform searches across multiple info files, and in part because Emacs simply has better navigation capabilities than any web browser.
Item 9: Master Emacs's regular expressions
--
条款9：掌握Emacs的正则表达式
++
The best way to do this is to get yourself the Friedl Book, Mastering Regular Expressions. It's worth it. Every programmer should have a copy, no matter what language or editor you're using.
Emacs's regular expressions have some idiosyncracies that everyone dislikes, but they're not insurmountable, and once you've learned them, it opens up new horizons in editing power.
Two important regexp-related commands are isearch-forward-regexp and isearch-backward-regexp. These are by default bound to ESC C-r and ESC C-s, respectively. Those keys are lame, though. Any sequence that requires hitting the actual Escape key is lame, and Alt-Ctrl-s on my Compaq machine is invisible to Emacs; it brings up a system diagnostics dialog.
I have the isearch-*-regexp commands bound to Alt-r and Alt-s, since I use them so much. Alt-s isn't normally bound. The default Emacs binding for Alt-r is the command move-to-window-line, which you won't need, because you'll use Item 4 for moving around within the window.
Some modes insist on re-binding Alt-r and Alt-s, which is annoying, and I have a bunch of per-mode hacks to re-bind them, but I don't have all modes covered. If someone can suggest a way to bind Alt-r and Alt-s in such a way that they can't be overridden by any modes, please let me know -- I'd be muchly appreciative.
The next two important regexp-related commands are replace-regexp and query-replace-regexp. They function identically, prompting for a regular expression and a replacement string, but query-replace-regexp prompts you to type y or n for each possible replacement.
I use query-replace-regexp so frequently that I have an alias for it:
(defalias 'qrr 'query-replace-regexp)
That way I can type M-x qrr to invoke the function.
Other useful commands that take regexps are M-x list-matching-lines, which shows you all the lines in a buffer that match some regexp, and M-x apropos, which shows you all commands whose names match a given regexp.
The most Frequently Asked Question about Emacs regexps is: "How do I insert a newline into a regexp or the replacement string?" Hitting the Enter key simply tells the command that you're done entering the regexp, and it starts doing the replacements. (This is a very good reason for preferring query-replace-regexp over replace-regexp until you're 100% confident that your regexps are right on the first try. I'm still not there yet.)
The answer is that you need to insert a ^J character, which Emacs uses to represent newlines in functions and commands. At the point in the regexp or replacement where you need to insert a newline, hit Ctrl-q followed by Ctrl-j. Ctrl-q is Emacs's "quote" command: rather than executing the following keystroke, Emacs will insert the key into the current buffer or the minibuffer.
Some other useful things to know about Emacs regular expressions:
* You need to double-escape ("//") regexp metacharacters in strings in elisp code, but you single-escape them when entering regexps at the minibuffer.
* Emacs code does so much matching of parens that Emacs regexps reverse the paren character and metacharacter. In an Emacs regexp, "(" and ")" match actual parens, while "/(" and "/)" create matching groups.
* In the replacement string, use /1, /2, etc. for inserting match-groups from the regexp.
* If you enter in a regexp and it doesn't work, undo the result if the command actually changed anything. Then type the command again, and when it prompts you, use the arrow keys to scroll up and down to find your regexp and replacement string, and modify them in place. This can save you a lot of typing and frustration.
* You can yank text into the middle of a regexp you're typing out with most regexp commands, but NOT in the isearch-*-regexp commands. Yank does weird things in those. I'd love to know how to fix this.
Mastering regular expressions and the commands that use them is one of the most important components of becoming an Emacs Wizard.
Item 10: Master the fine-grained text manipulation commands
--
条款10：掌握一套一致的文本处理命令
++
Emacs provides many small but useful commands for doing surgery on text. They add up to laserlike efficiency.
For starters, don't be tempted to re-bind Ctrl-k to a function that kills the whole line including the newline. I know that's the way kill-line works in all other editors. But it's clumsy and coarse compared to the way kill-line works by default. The default behavior, which kills the text to the end of the line but doesn't kill the newline, gives you finer-grained control, and leads to more efficient text surgery on the whole. Trust me: all Emacs users use other applications that only support the fat-fingered kill-whole-line version, so they've had plenty of opportunity to use both approaches. There's a reason the default is the way it is.
Keyboard Macros
I believe I can state without the slightest hint of exaggeration that Emacs keyboard macros are the coolest thing in the entire universe. They are, in a sense, as fine-grained and special-purpose as it gets, because you create them on the fly to solve specific editing problems. Whenever you find you need to make a specific, patterned change more than, say, 10 to 15 times, create a keyboard macro. It's really easy to do.
First it helps to do a trial run on the macro. Once you've done that, put your cursor at at the beginning of the first place to change, and use Ctrl-x ( to start recording the macro. Make your edits, and make sure to put the cursor in the corresponding place on the next line (or several lines down, as appropriate), so the macro will execute exactly the same pattern every time. To stop recording, type Ctrl-x ), and to invoke the macro, use Ctrl-x e (call-last-kbd-macro).
It's something of an art to define a robust macro -- you learn to use anchors like beginning-of-line and end-of line to make sure the macro is in a stable point before adding another action to it.
And incremental-search is useful for skipping forward to the next place to invoke the macro: if you use isearch within the macro, to find the place to start, then each invocation of the macro later will automatically perform the search each time. Very convenient.
And it's OK to make minor navigational mistakes while recording the macro. Just move the cursor back to where it should be and keep recording. The mistake will be replayed every time you execute the macro, but it'll happen so fast you'll be unlikely to notice.
The trick to getting good at macros is to be persistent: make sure you get the macro working, and don't give up, even if it means spending more time fiddling with the macro than making the edits manually. The next time around it'll be easier, and eventually they'll become second nature. Keyboard macros are one of the most powerful features of Emacs, and they can make your life much easier.
One last tip for keyboard macros: typically you'll play them dozens or even hundreds of times in a file, or across multiple files. You should bind call-last-kbd-macro to a single keystroke, such as the F5 key. You'll usually be "babysitting" the job, pressing the key over and over, watching the changes as you make them to ensure you don't hork something unintentionally. So it's fine to have it bound to a "faraway" key like F5. You can set it up like so:
(global-set-key [f5] 'call-last-kbd-macro)
Transpose-* functions
Finally you'll find the transpose-* commands surprisingly useful once you get used to them, even though they look like gimmicks. Probably the most useful is transpose-words. You'd be amazed at how often you find yourself using this command, which is bound to Alt-t. It has two uses: swapping two adjacent words, and dragging a single word forward or backward in a sentence.
The transpose-words function is aware of mode-specific syntax and word boundaries, so, for instance, putting the cursor between these two words:
([this])-is
and hitting Alt-t will result in:
([is])-this
You can transpose words across hyphens, HTML tags, and basically all punctuation. It's a pretty handy feature when you need it.
When you transpose 2 words, e.g. "dog food", the leftmost word swaps with the rightmost (assuming the cursor is somewhere between the beginning of the first word and the end of the second one), resulting in "food dog". But the cursor moves so that it's still to the right of the word that moved to the right. So if you apply it repeatedly, the word moves along the sentence to the right. I don't think there's a built-in way to make a "drag-word-left", but it would be easy to write a short function to do it. The corresponding Eclipse plug-in would be 5,000 lines of code in 60 source files and would take nine days to write and debug.
You can also transpose chars, lines, sentences, and paragraphs. These are all useful as you perform editing operations on your raw text and even your source code. Experiment with them and try to remember that they're there, and eventually they'll also become second-nature.
Tune in next time...
--
下次要写的东东…
++
At some point I'll have collected and documented 50 tips, at which point Scott Meyers can just eat his heart out. I made a valiant effort to do them all in one sitting, but I gave up just now and changed this blog's heading from "50 Specific Ways..." to "10 Specific Ways..." At least I did it this entry all in one sitting of a little over 2 hours. An Eclipse user would have spent that much time digging through the manuals, looking for a refactoring tool that can write blogs. Fat chance.
--
一开始我有点想写50个条款的，就像Scott Meyers的力作《Effective C++》那样写50个条款。
++
For upcoming tips, a few that come to mind as being particularly useful are:
1. fill-paragraph (Alt-p) -- intelligently line-wraps your text for you: an absolute must, and it works inside source-code comments.
2. gnuserv: automatically open certain document types (including View Source in your browser) in Emacs.
3. M-x Dired: a powerful way to manage your files and directories. It can do things that NO other tool can do (at least that I'm aware of), including renaming arbitrary groups of files from one regexp to another.
4. whitespace-manipulation commands: C-x C-o (delete-blank-lines), delete-trailing-whitespace, tabify and untabify, indent-region, and so on.
5. nxml-mode: the ONLY way to fly when you're editing XML. Authored by XML guru James Clark; it knocks the socks off any IDE-based XML editor out there today.
6. picture-mode: the best way to draw ascii art, and useful in a surprising number of situations.
7. minibuffer management: mastering recursive edits, learning how to abort from various situations, command completions, and other command-entry trickery.
8. effortless navigation: re-bind a few keys so that you can move the cursor in any direction, by chars or words, by holding down Alt and just pressing various letter keys.
9. region management: choosing a non-disgusting color for the highlighted region, covering region-related commands.
10. rectangle commands: yet another incredibly important set of related commands with no analogues in other editors. Once again, you'll wonder how you lived without them.
11. emacs shells: tips and tricks for getting the most out of a bash command shell running as an Emacs subprocess.
12. align-regexp: my new favorite command. just learned it recently, and I use it almost every day.
13. frame initialization: put Emacs exactly where you want it, every time it starts up, by auto-detecting the screen dimensions and computing where it should be.
14. using the goal column: things every Emacs power-user should know.
15. setting the fill column: how to get the most out of fill-region and fill-paragraph.
16. optimizing OS settings, such as speeding up your keyboard repeat rate, choosing an ideal Emacs font, and so on.
17. browsing and editing archives: tar, gzip, zip, jar, etc. Most people have no idea this feature exists, and it's nothing short of amazing.
18. advanced keybinding: learn the syntax for binding function keys, home/end, and other oddball keys. Learn how to make keybindings local to a particular buffer or mode.
19. mastering the kill ring, including using Derek Upham's fancy new mode for viewing its contents.
20. mastering Info: customizing your Info dir, finding and adding in new Info files, and advanced navigation and bookmarking.
21. using M-x customize: learn how this beast works, and how to use it or avoid it as needed.
22. utility apps: M-x calendar, M-x calc, and others.
The list goes on and on... ah, well, I'll get around to them someday.
And with that, it's a wrap! I'm heading to bed.
--
这个列表会一直增长下去……呵呵，在某天我会再把它们写出来吧。
就这么多了，我得睡觉啦~~~。
++
published Jan 23, 2005
last update, Mar 12, 2006
Comments -----------------------------------------------------------------------------------------------------
Some random comments:
To yank at the i-search prompt, use M-y instead of C-y. The emacs info node on Incremental Search talks about the rebinding of C-y, C-w, etc at the i-search prompt.
To repeat execution of the last kbd macro, after hitting C-xe to run it once, keep hitting just the 'e' key for repeated execution.
Zap-to-char (M-z) is incredibly useful if you need to change myDatafileHandler to myStreamHandler and point is at D (the first char to change). Simple M-z e to zap the "Datafile" part and type in the replacement. This is not orthogonal to the backward-kill-word (bound to C-backspace for me since that works in windows browser windows as well as everything else) so there's a feel needed for which is optimal when, which for me mostly depends on where point is already.
Posted by: Ami F. at January 23, 2005 07:12 PM
"Swap Caps-Lock and Control": Or you could just get yourself a keyboard that's already swapped, or that lets you swap them in hardware. The Happy Hacking Keyboard is an example of the former. I like the Avant Stellar keyboard for the latter.
"Binding Alt-r and Alt-s": Try setting up a minor mode with the definitions you want. Then stick that keymap on the *front* of MINOR-MODE-MAP-ALIST.
Other tips:
Use `iswitchb' mode. It's faster for switching between buffers, and it provides more feedback.
Use P4 mode. But be sure to download a more recent version than what we have installed.
Emacs' integration with X11 selections is written to work well with xterm's sucky default policies. That means it works badly with modern apps and badly over slow network connections (say, a VPN from home). I have written a new set of commands to make Emacs talk to the clipboard, and they make life much easier.
Posted by: Derek U. at January 24, 2005 07:37 PM
Doing the swapping of control/cap-lock key can be done in //HKEY_CURRENT_USER/Keyboard Layout instead of under //HKEY_LOCAL_MACHINE.
Posted by: Chris W. at January 27, 2005 07:52 AM
I disagree with your agressive rebinding of keys. I used to rebind almost all my emacs keys so they would be more familiar to a windows user (Ctrl+C does copy, Ctrl+V is paste, etc). However, I found myself at a loss when I tried using my neighbor's computer with the default emacs installed.
Always learn default emacs keybindings first, then over-write them as you find appropriate. For example, I rebound Ctrl+J to be the goto-line macro. By default, Ctrl+J enters a newline. F7 is not bound to anything by default, so I made that bound to the compile macro (that keybinding actually comes from Visual Studio). That is about the extent of the keybindings I need/use. And, if I have to use a non-customized emacs, I can still get work done.
Cheers,
-Brian
Posted by: Brian M. at January 27, 2005 10:29 PM
To not pursue aggressive editor and keyboard customizations because other people stick to the standard is a bogus argument, in my opinion. Firstly, how often do you really use a terminal other than your own? And even then, how often do you write just scads of code there? When I do this, it's usually for just a couple of quick edits. So, why optimize for that 1% of time when you're not at your own setup? Secondly, if it does annoy me enough to care, I can always just load my rc file remotely. I use vim and have my .vimrc hardlinked into my /workplace directory so I can just say vim -u /net/ericw/workplace/.vimrc if I really need my magic. I'm certain the same can be done in emacs.
Customization is one of the main selling points of powerful editors, and our wrists are two of our most valuable assets as developers, so I don't understand why people eschew customization just because they fear that small percentage of the time when they won't have it.
Posted by: Eric W. at January 28, 2005 07:34 PM
Brian, I'm afraid I'm with Eric on this one.
I have friends who have nonstandard keyboards, in some cases to avoid repetitive-stress injury. I can't type at their workstations. I have this little secret, though, that works like a charm. I say: "uh, you type."
OK, not much of a secret, but it's gotten me by.
Everyone customizes their environment. Some SDEs use fonts so small I actually can't read them. Some use custom window managers with non-CUA hotkeys and behavior. People use Windows, Linux, MacOS. There are different Unix shells with different default keybindings and aliases. Should we tell everyone they have to use plain-vanilla Windows installations with no customizations?
You're effectively arguing that we should all reduce ourselves to the least common denominator of productivity. This argument has been debunked in other domains (e.g. should we make people with good vision wear blur-inducing glasses, so nobody feels like they're at a natural disadvantage?), and it doesn't hold water in ours either.
You're welcome to use the default bindings yourself, of course. But I wouldn't get on a bandwagon that tries to discourage people from getting better at their jobs. It's a slippery slope that I think you want to avoid.
Anyway, we now issue laptops with wireless iVPNs, so you can even bring your environment with you. It's just not an issue anymore.
Posted by: Steve Yegge at January 28, 2005 09:30 PM
I just want to know the tips you allude to in number (8) of your "Tune in next time..." section. How do you do the up/down/left/right browsing? I've been trying to train myself to use C-n, C-p, C-f, C-b and friends, but its awkward, and it isn't getting easier. Also, can I plllleeeeasssseee see your .emacs file :)
Posted by: Charles G. at February 18, 2005 01:47 AM
On March 4 2006, Luke Gorrie wrote:
Howdy,
I know it's bad form to comment on a blog entry without having read it thoroughly but I will take a chance because your eternal salavation is at stake.
I use C-h for backspace in Emacs and move `help-command' elsewhere:
(global-set-key "/C-h" 'backward-delete-char-untabify)
(define-key isearch-mode-map "/C-h" 'isearch-delete-char)
(global-set-key [(hyper h)] 'help-command)
and this also works in the shell along with C-m, C-j, C-i, etc.
Offered for your consideration. :-)
On March 5 2006, Anupam Kapoor wrote:
hi,
regarding tip #7, imho, its better to just disable it via Xresources,
rather than loading it all up and making it invisible (as you have
shown) via:
,----
| ! better to turn this off here than in .emacs
| ! where it has already been loaded.
| emacs.menuBar: off
| emacs.toolBar: off
|
| ! no scrollbars fur me
| emacs.verticalScrollBars: off
`----
kind regards
anupam
On March 9 2006, Scott Anderson wrote:
Steve,
Great article.
Reading section 7, I became amused by the person who claimed that
"countless studies" (or whatever) had proven that the mouse was
faster.
I'm guessing he never studied GOMS, which is a method of decomposing
UIs into their basic operations and then performing objective
complexity and time analysis.
A quick typist can hit about 10 keys per second, or .1s per key. To
use a mouse there are four movements involved: move from the keyboard
to the mouse, move the cursor to a location, perform some operation at
the location, then move the hand back to the keyboard.
Moving the hand takes about .4s. Moving the mouse cursor on the screen
takes .5s. So without even doing anything, you've used 1.3 seconds. A
mouse click takes .1 seconds, and if you're dragging something, you
measure the click down, the drag, and the release, adding up to
another .7 seconds.
So let's say I want to highlight a line for copy:
mouse:
.4 move to mouse
.5 move cursor to first character
.1 depress button
.5 drag to highlight (and this is optimistic, depending on how good
you are with finicky targets like highlighting)
.1 release button
.4 move to keyboard
.2 copy (alt-w, ctrl-c, whatever. count control keys as a separate keypress)
2.2 seconds to perform.
kb scenario 1: best case: already at beginning of line
.2 mark (ctrl-space)
.2 end-of-line (ctrl-e)
.2 copy
.6 seconds to perform, or nearly 4 times as fast.
kb scenario 2: worst case: requires navigation: 30 lines down, line
starts with "Reading"
.9s move to start of line (ctrl-r readi ctrl-r)
.2 mark (ctrl-space)
.2 end-of-line (ctrl-e)
.2 copy
1.5s, still faster
As it turns out, the only thing a mouse is really good for is
something involving a gross motor movement, like moving a window or
the like. Unless you're a crappy typist.
Anyway, good article, and I'm looking forward to reading the rest of
them.
Regards,
-scott
Back to Stevey's Drunken Blog Rants image of my email address, steve dot yegge at ye olde gmail