Dealing with oh-so-many terminal windows

I have a problem. I have too many terminals and they tend to get lost. Emacs and vim and probably other editors are good at dealing with the problem of too many files, you just give every file a name, and then give people an easy way of finding open files by name.

I want to be able to do this with terminals.

---

Using screen

Screen works quite well for this: it allows you to name open terminals and then re-open these terminals by name. I’ve made this work by having an X terminal that connects to an existing instance of screen, this allows me to have a half-dozen interfaces to the same instance of screen at the same time.

However this approach has a couple of problems.

• No completion of terminal names (it does, however, allow you to just write buffer name prefixes)
• The default maximum number of windows isn’t high enough (the maximum of 40).
• You end up pressing F quite, as terminals seem to get temporarily broken every time you resize.
• Having a screen window open in two x terminals of different sizes confuses clients.

---

Trying to do this same in emacs

This would be a slightly nicer approach since emacs is awesome – and ido mode’s buffername completion is great.

However, some niggles in emacs have stopped me from doing this.

No curses in eshell

Emacs provides a light-weight shell (eshell). This allows you to interact will using your shell (copy and paste searching backwards etc). However it breaks curses, so no less, no mutt, no vim. This counts as unusable to me, as I tend to do things like open less on several hundred megabyte files on a remote machine.

ansi-shell to the rescue

Ansi-shell however does support curses, and vim and mutt, and beautiful colours. So this looked hopeful.

But not quite…

However, ansi-term just doesn’t quite work for the following reason:

• mutt doesn’t work. If you resize a window while using mutt, mutt breaks and draws things in random places
• Not fast enough! I like streaming large files with the F command in less, this can bring my terminal grounding to a halt

So yes, I’m settling with hacked version of screen for the moment.

Increasing the maximum number of screen windows

I’m not quite sure why I need more than 40 terminals but it appears that I do. I like to have a terminal for each different class of thing I’m doing (like reading though code, fixing bugs on by machine, doing things in a source tree, running tests, doing some recording to debug these tests, deploying, playing in a python shell, doing some stats in R) and then terminals logged into half a dozen machines, as well as poised to look at logs on these machine. The limit of 40 terminals poses a problem here, this is made worse by the fact that when the world catches file you often want to open a lot of new terminals – hitting up against limits exactly when you want to do things is not fun.

We can however increase screen’s window limit by rebuilding. On ubuntu we can do the following

apt-get source screen cd screen-blah-blah vim config.in # Set default MAXWIN to something sane like 500 dpkg-buildpackage cd .. dpkg -i <deb file that dpkg-buildpackage dumped in your parent directory> </pre>

This will work equally well for other debian-based builds (one presumes).