While learning about and configuring weechat this evening, I noticed a lot of complexity and unsatisfying tradeoffs related to its UI, its mouse support, and its built-in window system. Got to wondering what I'd do differently, if I wrote my own IRC client, to avoid those problems.

The first thing I realized is, it is not a good idea to think about writing your own IRC client. Danger will robinson..

So, let's generalize. This blog post is not about designing an IRC client, but about exploring simpler ways that something like an IRC client might handle its UI, and perhaps designing something general-purpose that could be used by someone else to build an IRC client, or be mashed up with an existing IRC client.

What any modern IRC client needs to do is display various channels to the user. Maybe more than one channel should be visible at a time in some kind of window, but often the user will have lots of available channel and only want to see a few of them at a time. So there needs to be an interface for picking which channel(s) to display, and if multiple windows are shown, for arranging the windows. Often that interface also indicates when there is activity on a channel. The most recent messages from the channel are displayed. There should be a way to scroll back to see messages that have already scrolled by. There needs to be an interface for sending a message to a channel. Finally, a list of users in the channel is often desired.

Modern IRC clients implement their own UI for channel display, windowing, channel selection, activity notification, scrollback, message entry, and user list. Even the IRC clients that run in a terminal include all of that. But how much of that do they need to implement, really?

Suppose the user has a tabbed window manager, that can display virtual terminals. The terminals can set their title, and can indicate when there is activity in the terminal. Then an IRC client could just open a bunch of terminals, one per channel. Let the window manager handle channel selection, windowing (naturally), and activity notification.

For scrollback, the IRC client can use the terminal's own scrollback buffer, so the terminal's regular scrollback interface can be used. This is slightly tricky; can't use the terminal's alternate display, and have to handle the UI for the message entry line at the bottom.

That's all the UI an IRC client needs (except for the user list), and most of that is already implemented in the window manager and virtual terminal. So that's an elegant way to make an IRC client without building much new UI at all.

But, unfortunately, most of us don't use tabbed window managers (or tabbed terminals). Such an IRC client, in a non-tabbed window manager, would be a many-windowed mess. Even in a tabbed window manager, it might be annoying to have so many windows for one program.

So we need fewer windows. Let's have one channel list window, and one channel display window. There could also be a user list window. And there could be a way to open additional, dedicated display windows for channels, but that's optional. All of these windows can be seperate virtual terminals.

A potential problem: When changing the displayed channel, it needs to output a significant number of messages for that channel, so that the scrollback buffer gets populated. With a large number of lines, that can be too slow to feel snappy. In some tests, scrolling 10 thousand lines was noticiably slow, but scrolling 1 thousand lines happens fast enough not to be noticiable.

(Terminals should really be faster at scrolling than this, but they're still writing scrollback to unlinked temp files.. sigh!)

An IRC client that uses multiple cooperating virtual terminals, needs a way to start up a new virtual terminal displaying the current channel. It could run something like this:

x-terminal-emulator -e the-irc-client --display-current-channel

That would communicate with the main process via a unix socket to find out what to display.

Or, more generally:

x-terminal-emulator -e connect-pty /dev/pts/9

connect-pty would simply connect a pty device to the terminal, relaying IO between them. The calling program would allocate the pty and do IO to it. This may be too general to be optimal though. For one thing, I think that most curses libraries have a singleton terminal baked into them, so it might be hard to have a single process control cursors on multiple pty's. And, it might be innefficient to feed that 1 thousand lines of scrollback through the pty and copy it to the terminal.

Less general than that, but still general enough to not involve writing an IRC client, would be a library that handled the irc-client-like channel display, with messages scrolling up the terminal (and into the scrollback buffer), a input area at the bottom, and perhaps a few other fixed regions for status bars and etc.

Oh, I already implemented that! In concurrent-output, over a year ago: a tiling region manager for the console

I wonder what other terminal applications could be simplified/improved by using multiple terminals? One that comes to mind is mutt, which has a folder list, a folder view, and an email view, that all are shoehorned, with some complexity, into a single terminal.

I wish that gnome-terminal was able to support multi-line URLs, or that mutt was able to render long urls on a single logical line.

If you use mutt in gnome-terminal, you may have noticed that urls that wrap to another line cannot be opened using gnome-terminal's context menu. Of course, resizing the terminal to be wide enough works around the problem, but is not always practical.

Another workaround is to pipe the message to less. While the url will still be displayed split across multiple lines, gnome-terminal will then recognize the whole url as one thing.

Why does less work where mutt fails? Well, it seems that mutt and less print the url differently. less simply prints the whole url, and lets gnome-terminal wrap it to the next line. mutt prints the first line of the url, then moves the cursor to the start of the next line, and prints the remainder.

This could be fixed either by making gnome-terminal smarter about finding the end of urls that are sent to it in multiple pieces, or by making mutt (or likely really ncurses) change how it outputs long lines.

40319

An e-book reader where I can click on any word and enter a definition for it. The definition will then appear as a tooltip when I hover over the word.

Take that, Iain Banks, and Neal Stephenson!

32

I want Deskview X's terminal program. The one that resizes the font when the window is resized. Except free and modern.

With modern (ie, auto-layout tiling) window managers, this is less of a wishlist and more of a missing necessity. Ideally, it would always keep the window 80 columns (or some other user-defined value) wide.

I've poked around in gnome-terminal's source, and this looks fairly doable, but I have not found the time to get down and do it.

Reading Paul Graham's latest as well as having written a few things today that involved considerable rewriting before I sent them out (this blog entry not^W amoung them!), I'd like the following:

A way, when saving a file in vim, to have it replay the undo buffer in reverse, outputtng whole series of snapshots documenting the changes that were made to the file. And an easy way to commit those snapshots, in order, to git, at the same time the final file is checked in.

This would address that period in the lifecycle of a file when it's too new, its author too busy, and its situation too precarious, for it to be checked in yet. These early stages can be very interesting, and generally go unrecorded.

discussion

Personal wishlist #5082

There should be a standard tag used to link to printable versions of web pages. Failing this, there should be some very good heuristics in the browser. No, I don't care about printing, but I do click on those little "print this page" links at every oportunity, same as I'll click on a link for a PDA or phone version of a web page when possible. Such pages tend to be much closer to the way the web should be: Devoid of stupid background colors, pointless graphics, javascript, and <blink>advertisements</blink>, and without of large sidebars. The web page sidebar is the late nineties and early naughties equivilant of the fifties tail fins on a car.

And "print this page" pages never have the dreaded "next page" link at the bottom. If I've decided to view your page, I want the whole thing, to drag off to my room and gnaw on and digest at my leisure offline; I don't want it doled out in little tidbits with a five minute delay in between each while I reposition the laptop for optimal wireless receptivity and download the next bit over a saturated phone line. So all I want is a way to view "print this page" pages by default.

Brr, it's cold. Not the most productive day ever either; I spent 2 hours fixing the remaining bugs in netcfg, but it seems that should have taken less time. I've very glad I got the new wireless card now, so I can use the net in a heated building. And I'm sorry to miss LinuxWorld this year, I had hoped to make it for at least one day and see several people again.

personal wishlist #5083

Are we all losing our short-term memories, or is it a fact of human nature that after typing in an email, we assume it's done, and just don't think about that attachment we promised to include with the email? I see it more and more often. .. Er, and I do it more and more often. I'm tempted to collect some data to see if this plagues mutt users more than users of other MTAs; we have to remember about the attachment all the way through to the end of the email, through saving it and existing our text editor, and only then tell mutt about it.

Anyway, so mutt needs a hook that runs before a mail is sent, with a nice little script that guesses when we promised an attachment, and left it out. Or, there needs to be a way to include an attachment on the fly, as soon as you type those fated words. I can think of several ways to do that, all hacks. OR, sendmail needs to finally grow that promised AI, and block at SMTP time emails that fail on their promises of attachments. Yeah!

personal wishlist 5084

I need a mail filter that downloads urls in emails, and if they are html, or plain text, attaches the first N kilobytes of them to the email (up to M kilobytes total per email, signatures excluded). It doesn't work to nag everyone to try and remember that some of us read mail while offline, and that we'd prefer that you include actual information that the email is about in the email. Besides, N may vary from person to person or time to time.

personal wishlist 5085

<email> or FOAF information in RSS feeds. Especially, but not only from planets. Hitting 'r' should just work, damnit.

personal wishlist 5086

I want a shell that does not actally chdir until it forks to run a command. Ideally this mode should be a toggle. Perhaps I work with crazy loopback / cronned mounts / umounts too much.

personal wishlist 5087

Given some random English text like this:

Go to foo.com, and scroll down to the bottom and click on the link for "special offers", then pick FrobNaz from the list, and click on the third link down on the next page.

.. I want an URL.