effective emacs中文版[7]

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而对本文全篇不爽。显然，他就是那种非常习惯于使用鼠标啊菜单啊之类东东的人，因此，觉得被称为“找不着北的新丁”很不爽。此君进一步阐述，说有无数的研究表明使用鼠标更加快捷。于是乎我也觉得自己应该把事情说清楚一点好：条款接下来的部分是全新的，这多亏了这位不忿的读者的Blog。

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.

首先要说的是，我也常常希望emacs能有一个更猛一点儿的显示引擎（译注：这方面Xemacs做得可以），可以有像其它桌面应用程序一样的GUI和图像功能。然而未能如愿啊；我的博客文章"The Emacs Problem"(译注：自己google一下吧)对此有所阐述。当然，我也乐于看到emacs没加入这种功能。。诶，我说这些是想表明，我不是个没头没脑的反GUI份子。

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.

由于用键盘就能达到同样效果，一般我都把emacs的滚动条关掉。然后，滚动条也有个好处：它可以很形象地显示出你在文本中的编辑位置及文本的长度；在状态区（译注:指mode line）的%-指示器不是那么好读取--无数研究都表明，确实如此。比如，这也是为什么美军在他们的反应堆中使用类似的比例量变尺。我们看数字时常出错，而读比例尺时不会~

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.

假定我们打算在一个很长的文本缓冲区的头部和尾部都插入包含80个连字符（-）的一行，而你现在又在文本缓冲区中间编辑。这个例子有些做作，但我还真是做过一些需要包含全部文本内容的剪辑工作。用键盘的话，我三秒就可以完成，并且完全回到编辑状态。我要按的键盘序列是："C-x t C-u 8 0 - RET C-x e C-u 8 0 -"

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.

如果你用鼠标，没有什么简易的方法能让你在3秒内做到这些事情。你想啊，你得往返两次去摸鼠标，抓住滚动柄，他它拖到第一行，这时候光标还不一定在行首，他就是说，你还得小心地点到那个位置去。

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.

当然，如果你勤加练习，可能5秒钟就得搞定，但何苦呢？如果经常要做这个，你应该写个宏啊。

Mouse use case #1 of 1: region selections.

鼠标用例(only 1)：区域选择

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.

有些操作明显用鼠标更快。在emacs之外与你的窗口系统交互，如果另一个程序没有类似emacs的键盘导航功能，用鼠标一般会更快捷。但是在emacs内部时，我能想到的鼠标比键盘方便的操作就是：区域选择，尤其是你打算选一个矩形文本时。

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 wth 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.

有时区域选择也是用键盘更好。比如，设定mark位置，然后用ctrl-n来选行，用ctrl-f一次多选一个字符。键盘的按键重复率是和硬件设定相关的，有时会觉得很慢。我自己的显示设定在一屏中可以包含大约100行。如果从中间移到屏幕底部，大约要用5秒。如果用鼠标来回操作，需要4秒。所以在可见区域选择时，用鼠标也不是很超值。

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.

使用鼠标跟关掉UI不是一个事儿，只不过是相关的事情，所以就搁一块说罢了；我20年前就做过这样的计时试验了。我衷心地建议你把菜单关掉~

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.

用菜单来探索，了解更多的emacs功能是不错的。不幸的是，它比较容易产生误导，让你认为emacs的功能就那么多了。其实，很多emacs扩展并没有什么菜单支持――只有非常细心的扩展模块设计者才会花时间去添加菜单支持。所以如果你想只用菜单来了解emacs，你会错过很多很多功能的。

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.

菜单的另一个问题，有点儿类似于之前我们提到的对话框：它没有很强的伸缩性能。如果你用菜单来给用户提供1500个选项，这个菜单的显示搞不好会把窗口整死的；便如果用Emacs的buffer来做，小case啦，还有很诸如漂亮布局和分组显示等额外的好处。你用M-x list-colors-display或者M-x list-faces-display就知道我说的东东了。

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.

菜单还有一个（大）问题，它没有自动补全~当你查看到一个比较深的子菜单层级中，以不小心进错一个子树时，很容易觉得自己是迷路了。没有什么探索方法比较可搜索的帮助系统更加灵活了，在MS的程序中是这样，在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.

所以我觉得emacs菜单不好：不能展现emacs全部的功能；不能给出提示帮助你找到你想要的功能；选择一多时菜单又撑不住（所以相比于树视图之类的组件，它不算是一个很通用的UI机制。）；当你知道怎么用时，用起来又很慢。

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.

简单来说呢就是：关掉菜单！就像那些闪亮的按钮一样~诶~~任何重要到要提供一个快捷按钮的操作，都应当有个快捷键。