Following on from my last productivity post, here’s an area in which I’m not excited about the time-saving new features I’m using, but would love to be: gnome-terminal. I see that it just branched for 2.14, leaving us free to fantasize about new features for HEAD. Here’s my top three:

Local search through scrollback:

screen(1) lets you search through scrollback. I do so a lot. But I wish it was better:

  • There’s no incremental search, and matches aren’t highlighted as you type (as in an emacs search-forward or vim hlsearch), which means that you don’t know whether the next match is going to be on the line above or the page above until you hit return and look around to see where the cursor went.
  • The latency is on the wrong end; when working over ssh tunnels, or on a low-bandwidth connection, it’s painful to try and operate screen’s search, leaving me making typos and confused and accidentally falling out of copy mode and ending up at the tail of the terminal again. You’ve been there, you know what I’m talking about.
  • I don’t run the majority of my shells inside screen, and there’s no way to stick the contents of an terminal inside screen once you realise you need to search through it.

Personally, I think this is a pretty compelling argument for local, incremental search through scrollback. Anyone else?

Horizontally-stretchable views:

I work in terminals with a lot of text (e-mail) and a lot of program (make) output, and want to minimise paging up and down — if you do too, you probably try and resize your terminal such that it’s still around 80 cols, but is the height of most of your screen. That’s fine, but vertical screen space is expensive; you can only do that for a small number of terminals.

This got me thinking about extending the terminal horizontally, such that text scrolls off the right segment of a terminal and immediately onto the left segment, where each segment is 80×24 or whatever. For more details, see the feature request I filed in GNOME Bugzilla asking what the gnome-terminal maintainers think about this.

Display-independent terminals:

I don’t care about this feature as much, but it’s a logical step forward from the separation of model and view that the last feature requires. Your gnome-terminals could exist outside of the X server they were started from and be attached/detached from X servers at will, as you move around; this is already possible with some X applications. The use cases are keeping terminal state between work and home, or even more importantly for me: not having to worry about losing terminals when your X server restarts.

Does anyone think any of these have potential?

Also, hello to Planet GNOME! You might be interested in my previous posts on zsh/ssh/emacs
and Linux on the Treo 650. If anyone’s willing to come up with a Hackergotchi for me, there’s a photo here. Thanks!


  1. Hi, welcome to my favourite planet ;)

    #define IMHO 1

    A feature really useful would be a yakuake/greent mode.

    Why use an “external” terminal when gnome-terminal can do this? It should be great, almost everyone needs terminal at any time, this mode of show a terminal rocks!

  2. > cryopid

    Would that actually help me import scrollback to a screen session, though? The scrollback is a function of the *previous* program state, not the current or future states.

  3. The display independant terminals are a nice idea; but my instinct is that such a feature should be done at a lower level, so that it’s not only terminals, but entire GNOME sessions that can be detached and re-attached.

    I recall a post on the planet about preliminary support for this in GDM, but I suppose nothing major has come of it yet

  4. The display independant terminals would be really great if you could use them with screen later via ssh, for example, and the other way around. That’s the one feature I’d love an X terminal emulator to have.


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>