RYAN MCGUIRE

256 colors on the Linux terminal

I've been using Linux as my main OS for well over a decade now. I can hardly believe I didn't pick up on this tip before.

On your linux desktop, open up your favorite terminal emulator. Enter this command:

tput colors

What number do you see? 8?

8 stinking colors. That's what my terminal is capable of displaying. It's 2009 folks, and my terminal can only display 8 stinking colors.

Load up emacs in the terminal (emacs -nw) and see for yourselves, M-x list-colors-display shows you all of the different colors your terminal can display.

Pitiful.

Ok, so how to improve this? On ubuntu:

sudo apt-get install ncurses-term

and stick the following in your ~/.bashrc and/or ~/.bash_profile:

export TERM=xterm-256color

Ahhhhh...

My Emacs config on Github

The most popular post on this blog is Emacs as a powerful Python IDE. I get quite a few emails regarding that post and I realized the other day that I've done a lot of customizations to my .emacs, and subsequently that post is starting to get a little dated. Time is a curious creature, it seems like yesterday that I wrote that post, but it's been almost 9 months now.

I've been learning and playing around with git recently, so I've decided to post my entire .emacs config on github.

Here are the latest instructions for emulating my Emacs environment on Ubuntu 8.10:

• Enable the universe repository
• sudo apt-get update
• sudo apt-get install emacs-snapshot git-core automake libgconf2-dev texinfo python-setuptools
• cd ~
• git clone git://github.com/EnigmaCurry/emacs .emacs.d
• cd ~/.emacs.d
• git submodule init
• git submodule update
• cd ~/.emacs.d/vendor
• ./vendor-compile.sh
• sudo easy_install "http://downloads.sourceforge.net/rope/rope-0.9.1.tar.gz?modtime=1225268769&big_mirror=0"
• sudo easy_install "http://downloads.sourceforge.net/rope/ropemacs-0.6.tar.gz?modtime=1223039342&big_mirror=0"

I've done some reorganization of the directory structure:

1. There actually is no ~/.emacs file anymore, having realized that Emacs looks for ~/.emacs.d/init.el. Convenient!
2. All third party packages are now installed in ~/.emacs.d/vendor. This was a great tip I saw in the Emacs Peepcode screencast. (it's $9, but worth it).
3. I've taken the suggestion that greg made in the comments to use submodules for some of the vendor packages. The vendor-compile.sh script does the compiling of those packages.
4. All private code goes in ~/.emacs.private. This lets me keep passwords and such outside of the main git repository and allows me to publish my config more easily. Before I did this I had to spend time sanitizing the code before each release.

I have appreciated your many encouraging Emails and comments. :)

Extending Emacs with Advice

The greatest single thing about Emacs is it's extensibility. If you think Emacs is missing something, or don't like how something works, you can change it. But that's true of any open-source software. The difference with Emacs is how easy it is to make that change.

There are several different strategies to extend Emacs. I'll list a few of them in order of hardest to easiest (and arguably from worst to best):

• Write your own major or minor mode from scratch.
• Edit someone else's mode (and hopefully submit a patch.)
• Write an Advice function.
• Write a Mode Hook.

Where Advice fits in

(Don't worry, I get into the meat of it in the next section. For the impatient, skip down.)

Mode hooks are almost always the easiest and best way to extend a particular mode, but they are also limited in scope. The author of the mode created these hooks specifically to allow you to extend his mode, and are therefore the best maintainable way to extend a mode (the author is unlikely to remove those hooks in future versions). However, if the author didn't anticipate certain functionality and there is no appropriate hook provided, you'll have to come up with a different solution.

At this point, obviously, you could just write your own mode -- but what a pain that would be if you already have something that's close to what you want. So why not just edit that particular mode to suit your needs (perhaps creating that missing mode hook yourself?) This approach is probably the best one especially if the feature you want is something other people would benefit from. You can submit your changes as a patch to the original author and (if he accepts them) your changes go into the next release.

But what if for some reason your changes are not acceptable to the author? You can still use your changes on your local machine, but every time a new version of the original mode comes out you'll have to merge your changes back into that new version. At this point you've successfully "forked" the project, but that's usually a bad thing in the long run.

One other option exists to Emacs developers: advice. Advice allows you to wrap existing functions with your own functions. This allows some types of behavior to be modified without even having to change the original file at all. You can keep your changes completely separated in your own customized files. This gives you the benefit of inheriting new versions of the mode by simply downloading the new version and putting it in your load path. In most cases your advice function will continue to work on the new version and you didn't have to merge any changes at all. If significant changes have been made you may need to modify your advice function, or create a new one, but you still won't need to merge any changes.

Continue reading and I'll give you a real-world example of how I've used advice, but I want to first re-iterate the proper use cases of advice:

• If you can use the mode hooks provided by the author, use them instead.
• If there is a bug in the original mode, just fix it in the original code and submit a patch.
• If there is a new feature you want, add it to the original mode and submit a patch. Talk to the author, work with him, and it will most likely end up in the next release.
• If you are an Emacs developer, working on Emacs itself, or one of the modes shipped with Emacs, never use advice. It's the least maintainable method of extending Emacs with the exception of a pure fork, and since you're working on Emacs itself, it's not a fork.
• If your patch is not accepted, or you know that what you want is fringe enough or hackish enough to not warrant submitting a patch, only then should you use advice or fork the project.

Using Advice

Alright, onward to the example I promised. I really liked the tip over at Minor Emacs Wizardry on combining EasyPG with Org mode -- it's an awesome way to keep a lot of things in an organized and encrypted way -- I use it all the time now.

My main machine is running Ubuntu and it's default GnuPG agent is Seahorse. It's actually a pretty nice manager for encryption (SSH and PGP) and is completely integrated with the Gnome desktop. The one problem I have with it is that I use Multi-TTY Emacs and when I'm using a terminal on a remote connection and I try and open an encrypted file, Seahorse pops up on the desktop instead of prompting me for the passphrase on my remote connection. In the past I've had to fire up VNC to my desktop just so that I could enter the password; damn inconvenient.

I could setup something like keychain, it's a real nice GPG agent that works equally well on the desktop as on the console. I've used it in the past and liked it. Seahorse requires no setup though, it comes with Ubuntu by default, and like I said, I really quite like it.

So, when I'm on my remote connection and Seahorse doesn't have my password cached, I'd like to be able to bypass the GPG agent entirely and just enter my password. EasyPG doesn't appear to have this functionality so I added it with advice:

(defadvice epg--start (around advice-epg-disable-agent disable)
  "Make epg--start not able to find a gpg-agent"
  (let ((agent (getenv "GPG_AGENT_INFO")))
    (setenv "GPG_AGENT_INFO" nil)
    ad-do-it
    (setenv "GPG_AGENT_INFO" agent)))

That little bit of code wraps the main EasyPG function that will ask for a password. It temporarily removes the environment variable that EasyPG looks for to connect to the GPG agent, and therefore EasyPG asks the user for the password as if there were no agent running.

Let's analyze the different parts of that advice function:

• All advice starts with a "defadvice" definition.
• "epg--start" is the name of the original function I'm wrapping.
• "around" is indicating that I'm specifying code to run both before and after the function I'm wrapping (other options would include "before" and "after")
• The word "disable" means that the advice is initially turned off (you could say "activate" to have it immediately turned on, read the manual for more options here)
• Starting with the "let" function is the body of my custom function
• The "ad-do-it" line in the middle is the point in the function where the original function gets executed. (This would not be used in a "before" or "after" style function.)

One more important thing to understand about advising a function is that you aren't creating a new function with a new name. You are adding data to the existing function definition. Wherever the original function gets called, your advice will be called along with it. However, advice does offer the convenience of turning on or off your changes. For the above example I added two user commands to turn on and off the GPG agent (bound to M-x epg-disable-agent and M-x epg-enable-agent):

(defun epg-disable-agent ()
  "Make EasyPG bypass any gpg-agent"
  (interactive)
  (ad-enable-advice 'epg--start 'around 'advice-epg-disable-agent)
  (ad-activate 'epg--start)
  (message "EasyPG gpg-agent bypassed"))

(defun epg-enable-agent ()
  "Make EasyPG use a gpg-agent after having been disabled with epg-disable-agent"
  (interactive)
  (ad-disable-advice 'epg--start 'around 'advice-epg-disable-agent)
  (ad-activate 'epg--start)
  (message "EasyPG gpg-agent re-enabled"))

These functions use the (ad-enable-advice) and (ad-disable-advice) functions respectively. Whenever advice is switched on or off, a call to (ad-activate) must also be made on the function to update it.

The manual goes into more depth about how to advice functions. Hopefully you got something useful out of this, I sure learned a lot in writing it.

Emacs ansi-term tricks

Being on vacation is soo nice. With some of my free time I'm planning on revamping my emacs environment, so hopefully that means a few more articles showing up here on that topic.

I read some great tips on ansi-term. Ansi-term is a terminal emulator written in emacs lisp that is as close to a real terminal as possible. That means you can run virtually all command line programs, even the ones that use ncurses like top or screen, all within emacs. You can still switch between line and char modes which means you can still edit the buffer as you could in a regular (emacs) shell too.

F2 Keybinding

In the above mentioned article Joseph wrote a nice little bit of elisp to get to a running ansi-term efficiently, by hitting F2. The nice thing about it is that it does what I mean:

1. If I'm already in an ansi-term, but it's called "*ansi-term*" rename it.
2. If I'm already in an ansi-term, but it's called something else, start a new ansi-term called "*ansi-term*"
3. If I'm in another non-terminal buffer, switch to a buffer called "*ansi-term*" or create a new one if it doesn't exist

There's one more catch though, as Joseph explains, an ansi-term can be considered "stopped" such that it is no longer running but the buffer still exists. In that case I don't want the third rule to switch me to a defunct terminal, so instead I want it to kill the buffer and create a new ansi-term. Here is my enhanced elisp:

(require 'term)
(defun visit-ansi-term ()
  "If the current buffer is:
     1) a running ansi-term named *ansi-term*, rename it.
     2) a stopped ansi-term, kill it and create a new one.
     3) a non ansi-term, go to an already running ansi-term
        or start a new one while killing a defunt one"
  (interactive)
  (let ((is-term (string= "term-mode" major-mode))
        (is-running (term-check-proc (buffer-name)))
        (term-cmd "/bin/bash")
        (anon-term (get-buffer "*ansi-term*")))
    (if is-term
        (if is-running
            (if (string= "*ansi-term*" (buffer-name))
                (call-interactively 'rename-buffer)
              (if anon-term
                  (switch-to-buffer "*ansi-term*")
                (ansi-term term-cmd)))
          (kill-buffer (buffer-name))
          (ansi-term term-cmd))
      (if anon-term
          (if (term-check-proc "*ansi-term*")
              (switch-to-buffer "*ansi-term*")
            (kill-buffer "*ansi-term*")
            (ansi-term term-cmd))
        (ansi-term term-cmd)))))
(global-set-key (kbd "<f2>") 'visit-ansi-term)

TRAMP Integration

Put the following inside of your .bash_profile on any computer that you ssh into frequently:

#Emacs ansi-term directory tracking
# track directory, username, and cwd for remote logons
if [ $TERM = eterm-color ]; then
    function eterm-set-cwd {
        $@
        echo -e "\033AnSiTc" $(pwd)
    }
    
    # set hostname, user, and cwd
    function eterm-reset {
        echo -e "\033AnSiTu" $(whoami)
        echo -e "\033AnSiTc" $(pwd)
        echo -e "\033AnSiTh" $(hostname)
    }
    
    for temp in cd pushd popd; do
        alias $temp="eterm-set-cwd $temp"
    done
    
    # set hostname, user, and cwd now
    eterm-reset
fi

Now when you ssh into a machine from within ansi-term and open a file with C-x C-f you'll be loading a file via TRAMP from the current working directory on the remote machine. Amazingly cool.

Ubuntu: coping with a height restricted display

I'm eagerly awaiting my new Samsung NC10 to be shipped from Amazon. It's a nice little netbook that I can use when traveling and when going to social occasions. I'm specifically buying this laptop because of its small size, but I know that one thing specifically will bother me: the screen resolution, at 1024x600 is wide enough for most tasks, but not very tall at all.

So while I'm waiting, I'm playing around with Ubuntu 8.10 inside a VirtualBox instance. I've got the window resized to 1024x600 and am playing around with different settings to make maximum use of the screen. Here are my tweaks:

Gnome Panel (the toolbar):

Open gconf-editor (Alt-F2 'gconf-editor') and navigate to apps -> panel -> toplevels -> top_panel_screen0 and change the following:

• auto_hide: checked -- makes the main toolbar panel autohide
• auto_hide_size: 0 -- makes the toolbar completely hide instead of leaving a few pixels visible
• enable_animations: unchecked -- make the hiding/unhiding as fast as possible
• hide_delay: 500 -- makes the toolbar stay on screen for half a second after using it
• unhide_delay: 0 -- makes the toolbar immediately popup when your mouse goes to the very top (or bottom) of the screen

Gnome Terminal:

Open the default profile properties, right click in the window and click "Edit Current Profile"

• Turn off the menu bar: on the General tab uncheck "Show menubar by default in new terminals"
• Turn off the scrollbar: on the Scrolling tab select "Scrollbar is: Disabled"

Oversized windows:

Uncheck the following key in gconf-editor:

Now you can Alt-left-click any window and drag it around even above the top of the screen.

Firefox:

• Move the bookmarks bar up to the file menu bar and get rid of the bookmarks bar:
  • Right click on the Home button and click customize.
  • Your bookmarklets should now disappear and read "Bookmarks Toolbar items."
  • Drag "Bookmarks Toolbar items" along the right hand side of the File .. Edit .... Help menus.
  • Click "Done."
  • Right click on the now empty bookmarks toolbar and uncheck "Bookmarks Toolbar."
• Get rid of the status bar: Go to View -> uncheck "Status Bar."
• Install a theme that uses smaller buttons and text: I like Classic Compact.
• Remember that Firefox has a nice fullscreen option : F11.
• Check out Tree Style Tabs. It puts the tabs vertically on the left side of the browser and visually keeps track of what sites you were at that prompted you to open a new tab, all in a tree like fashion.

Here is the desktop with gnome panel completely hidden and one terminal with menu bar hidden (click to see native size):

Here is firefox maximised with two tabs open (click to see native size):

Here is firefox in fullscreen (click to see native size):

Firefox maximized with Tree Style Tabs: