fuzzy notepad

Tagged: tools

[blog] Elegance

Programmers sometimes like to compliment code as elegant, yet I can’t recall ever seeing a satisfying explanation of what “elegant code” is. Perhaps it’s telling that I see “elegant” used much less often by more experienced programmers, who opt for more concrete commentary.

Surely elegance is a quality to strive for, but how are we to strive for something we can’t define? “I know it when we see it” isn’t good enough.

I think about this from time to time. Here’s what I’ve come up with.

[blog] Text editor rundown

As part of my experiment to monetize my personal brand, or however we’re describing this now, I have a milestone that lets a patron impose a blog topic of their choosing on me. What could possibly go wrong?

And so, this month, Russ brings us:

You should totally write about text editors.

I totally should. I mean, wait, no I shouldn’t. I haven’t seriously used a text editor other than Vim for years.

Thankfully this was a moderately vague request, so here’s what I’ve done: I’ve subjected myself to all these hip shiny text editors that I haven’t been bothering with and taken notes of my initial impressions. I only had a few hours to devote to each, so this won’t really be a fair comparison
 but you know, life isn’t fair, so eat your peas and do your homework.

[blog] tmux is sweet as heck

People occasionally ask me why tmux is significantly better than screen, and I end up mumbling the first few things that come to mind. This has yet to sway anyone. Here, then, are some things that I enjoy about using tmux.

First, some terminology, so the rest of this makes any sense at all.

  • tmux and screen, if you were not aware, are multiplexers—they let you run multiple terminals (or terminal programs) at the same time, switch between them, and disconnect or close your terminal without killing everything you were running. If you didn’t know this then you should probably stop now and poke around tmux’s site or something.
  • A session is a particular group of terminals owned by tmux (or screen). When you run tmux bare, you get a new session.
  • A window is a numbered terminal inside a session.
  • A pane is each compartment within a split window. (I lied above; a window might actually have several panes and thus several terminals. But a window is identified by one number.)
  • An xterm is a single GUI terminal window (or tab). You may be using another terminal emulator, or you may be in a non-GUI virtual terminal; I’m using “xterm” as an umbrella term for all of these.

I’m also assuming that ^A is your multiplexer trigger key, although tmux defaults to the more awkward ^B.

Works out of the box

Here’s my .screenrc, fiddled by hand over the course of many months after I started using screen.

1
2
3
4
5
6
7
8
9
caption always "%{= kw}%?%-Lw%?%{Kw}%n*%f %t%?(%u)%?%{kw}%?%+Lw%? %=%{= dw} %H "

# terminfo and termcap for nice 256 color terminal
# allow bold colors - necessary for some reason
attrcolor b ".I"
# tell screen how to set colors. AB = background, AF=foreground
termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm'
# erase background with current bg color
defbce "on"

What the fuck is any of this? The only real configuration here is the first line, which sets a fairly simple status bar. The rest is unreadable sludge picked off of Google to make terminals inside screen work the same way as terminals outside it. I see this as a serious failing in the one core feature that defines a multiplexer: being invisible.

Some of this might not be necessary any more; maybe termcaps have been improved in the meantime. Part of the very problem is that I can’t know; the best I can do is delete bits of it and see if screen still behaves correctly, assuming I remember all the quirks I was trying to fix in the first place. It’s 2012. I shouldn’t ever see the word “termcap”.

Contrast with tmux, which just worked. The only terminal-related fudging I ever had to do was set my $TERM to xterm-256color for it to respect 256-color sequences. Not entirely unreasonable.

tmux can also inherit parts of the environment when it’s detected a change; by default it looks for some common X and SSH stuff. The upshot of this is that your SSH agent continues to work across SSH connections; the new environment only applies to newly-created windows, but zero hacks are necessary.

By default as of tmux 1.6 (I think), when you create a new window, it’ll get the same current working directory as the current window.