Wednesday, December 30, 2009

Visual Studio Emacs Keybindings: Getting Indent to Work Properly

I'm a hard-core Emacs user, but sometimes I have to use Visual Studio. A friend of mine just pointed me to a brilliant blog post that describes how to set up Emacs key-bindings in Visual Studio. (Briefly: Go to Tools Options Environment Keyboard, and select Emacs from the list of key mapping schemes.)

The only problem I found with the procedure: when you hit enter to move to the next line, the cursor goes back to Column 1, and unlike in Emacs "Tab" does not automatically move you to the proper column to continue the block of code you're writing.

I found a way to fix this:

  1. Go to Tools Options Environment Keyboard
  2. In the dialog box labeled, "Show commands containing:", type "breakline". Wait a moment for the search to complete.
  3. Select Edit.EmacsBreakLineIndent.
  4. In the "Use new shortcut in:" menu, select "Text Editor". This tells Visual Studio you want the binding we're about to add to be active only while in the text editor.
  5. Click in the "Press shortcut keys" box, and hit Enter. The word "Enter" should appear.
  6. Click "Assign."
You'll get a warning that Enter is already assigned to Edit.EmacsBreakLine. You're reassigning it to EmacsBreakLineIndent. Now, when you hit enter, the cursor is automatically positioned at the correct column to continue typing a code block.

To switch back to the old behavior, follow the same procedure as above, except select Edit.EmacsBreakLine instead.

How to fix xterm on cygwin when the alt-key doesn't work

Most of my keystrokes go into xterm, and from there to my shell, tcsh. (Some people use bash, which has the same problem.) Shells typically let you use emacs-like commands to edit your command-line -- for example, Control-B to move back one letter, Alt-B to move back one word; Control-F to move forward one letter, Alt-F to move forward one word. Unfortunately, some combinations of X Window server and xterm options doesn't correctly get the alt-key all the way through to the shell.

I use Cygwin under Windows, and sometimes when I type Alt-B into my xterm window, instead of going back one word, I'll see a weird control-character, like this: รข.

There are two ways I've found to fix this: one for an xterm that's already running, and one for launching future xterms without this problem.

For xterms that are already running:
  • Left-click inside the xterm
  • Hold down the Control key, then left-click and hold the left mouse button. This will bring up a context menu.
  • Scroll down to "Meta sends escape" -- it's about halfway down
  • Release the mouse button
To get future xterms to run with this option:
  • Edit the command-line you use to run xterm to include the following argument:
-xrm "xterm*VT100.metaSendsEscape: True"

Here's an example of a complete xterm command including that argument:

xterm +tb -xrm "xterm*VT100.metaSendsEscape: True"

This tells xterm it should convert "Alt-B" into a two-keystroke sequence: Escape, then B. It gets around systems where, for some reason, the keyboard-to-shell path is not 8-bit clean.

Tuesday, December 15, 2009

A place to post random, obscure technical tips

Sometimes, I'll spend hours trying to solve some random technical problem that no one seems to have solved before. When (if!) I finally succeed, I often feel an obligation to somehow store that hard-won knowledge in the Internet. This blog serves no purpose but as a dumping ground for that kind of knowledge. My hope is that by posting technical tips in blog form, search engines will index it, and in the future, people suffering from the same problem will find it. Plus, since blogs allow comments, they'll be able to say, "Hey, it worked!". Or not.