Stupid colour, stupid slime, stupid emacs


Why is it so many things try and customise the colour of something and so many things get it wrong?

I’d heard lots of good things about slime. I’m learning Common Lisp, so I decided to try it out. The first thing I notice is how much junk this adds to my .emacs. My emacs startup time goes from about 500ms to about 1500ms (oh okay, I actually went and measured it; it turns out that emacs has a command line option specifically for timing how long it takes to startup (well, is there any other use for emacs --kill ?). Anyway, old version: 29 ms, new version: 246 ms. To my surprise vi (vim really) is slower at 46 ms. The mighty ed scores 11 ms).

Oh well, I only use emacs for 3 things anyway: reading the info documentation for stupid GNU tools that think that I shouldn’t be using man to read my documentation; testing and debugging what little emacs lisp I write; inferior-lisp-mode. Anyway, the next thing I notice is that my prompt is cyan. This colour just happens to clash horribly with the colour of the Terminal window in which I am running emacs (which is #E78C3F). THIS HAS TO STOP. Coloured slime. Great. Should slime start with colour enabled? No. Should slime provide the ability to decorate its UI in colour? Of course. There’s no way that any particular default colour scheme provided by slime will match an arbitrary colour scheme chosen by me, so that’s why it shouldn’t use colour by default.

I think I have some sort of default colour scheme curse. All you hackers out there writing colour schemes must use ultra-black or something; I generally run my Terminal windows with a light background and black ink, and I often fall foul of default colour schemes for stupid programs that stupidly use colour by default. All you people creating ad-hoc colour schemes for your crappy little tools (slime, emacs, vi, ls) stop it. Make sure the default is to not change any colours.

So I spend another half-hour trying to find and change the relevant parts of customize-group slime (naturally this involves finding a bug in this interface which makes it impossible for me to save any changes the first time). Part of the customize-group interface are almost unbearably unreadable because of the choice of colour. Great, now my .emacs has grown from 2 lines to 17. It’s the start of a slippery slope.

Would you like to see how bad info-mode looks? Okay, here it is: Emacs screenshot with nasty clashing colours

I knew I was right to fall in love with FreeBSD when I saw Linux embrace colour ls.

3 Responses to “Stupid colour, stupid slime, stupid emacs”

  1. drj11 Says:

    The Right Thing, as suggested by a friend of mine, is to put (tty-color-clear) in my .emacs file. This restores emacs to a black-on-white editor, as God intended. (in fact, whatever colour scheme I’ve chosen in Terminal)

  2. YAJer Says:

    Another use for emacs –kill is stuff like (assuming I’ve not gotten some stupid detail wrong)

    emacs -l $HOME/el/batch.el –kill

    or, maybe

    emacs -l batch.el -f main –kill

    Because, you know… maybe perl doesn’t eat enough cpu for some people.

  3. DJW Says:

    Switching to FreeBSD after seeing colour ls…
    …Amen to that, brother, amen to that…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: