This article was written by Steve Yegge and originally appeared at
http://www.cabochon.com/~stevey/blog-rants/effective-emacs.html.
Retrieved from Google cache on 2006-09-06 by Nelson Ayuyao. I'm hosting it here until Steve's server comes
back online. --Michael Leonhard
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.
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.
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.
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.
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.
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.
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.
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.
The rest of you: I think your Eclipse just finished launching, so you can get back to work now.
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:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout
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.
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
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.
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.
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.
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.
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.
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)
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.
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.)
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.
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)
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.
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.
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:
For mistakes further away, I'll use Fast Navigation to get there: Item 4 covers at least part of this technique.
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.
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.
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.
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.
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.
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.
If you plan on keeping multiple temp buffers around, you might give them more memorable names, such as foo, bar, baz, and 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.
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.
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.
The most important commands to master are:
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.
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.
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.
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.
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.
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.
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.
Once you learn to master those buffers and windows, and sling them around with ease, you'll be on your way to Emacs Wizardhood.
(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.
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.
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.
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.
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 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.
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.
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:
Mastering regular expressions and the commands that use them is one of the most important components of becoming an Emacs Wizard.
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.
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)
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.
For upcoming tips, a few that come to mind as being particularly useful are:
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
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