

Ask HN: What do you look for in a terminal? - makecheck

Aside from "obvious" things like speed, accuracy, etc. what kinds of features do you really want in a terminal emulator (especially if you don't know of any terminals that do what you want)?  What are a few really important things that just seem to have been dropped?<p>I develop a Mac terminal emulator, and a friend once asked me <i>why</i>.  His reasoning was that the OS already had one, and that seems to be a recurring theme with bundled software: people don't tend to ask for features beyond what OS-bundled apps already provide.  So I thought I would finally ask; are people really content with what's there out of the box?
======
thaumaturgy
I've used iTerm2 (<http://www.iterm2.com/>) for quite a while, especially for
its full-screen mode (a must-have) and its semi-transparent capability (total
vanity there). Importantly, the full-screen mode is actual full-screen,
without a menu bar or any other nonsense. Switching between terminals is easy.

I can't really think of anything else in a terminal program that I'd look for.
Good font rendering, obviously. Huge scrollback buffers would be nice. Maybe
better copy-paste handling?

I can still use MacOS X's built-in terminal app, and I often do when working
on a client's computer, but it feels really inelegant now by comparison. A
little like having to give up your favorite ratcheting box wrench set for
standard combo wrenches.

~~~
makecheck
I think I have all the things you mentioned, aside from semi-transparency
(which I only use when the app is backgrounded).

My full-screen mode can fill 2 displays, with the most-recently-used window on
each display; and by setting options everything else can be removed, like the
menu bar.

What is the ideal way to switch between terminals? Right now I rely on the
window manager, e.g. command-tilde keys, clicking with the mouse, Exposé, and
I have a separate window that lists every open window (also usable for
switching).

What would make copy-paste handling "better"? I did implement a way to get
auto-copy-on-select like Unix terminals do, and drag-and-drop. I also detect a
multi-line paste, which provides an option to join into a single line. Larger
pastes are buffered to try to avoid overwhelming the program running in the
terminal.

~~~
thaumaturgy
> _What is the ideal way to switch between terminals?_

I like command-option-(right or left arrow). I don't usually have so many
terminals going simultaneously that it's difficult or annoying to cycle
through them or keep track of their order.

> _What would make copy-paste handling "better"?_

Well, I often enough find myself copying e.g. config file contents from one to
another, along with path names and maybe a password or two. Sometimes I have
to create a scratch text document to store the pieces, so something like a
command-option-v to bring up a floating clipboard buffer would be pretty cool.
But, I know that the right answer to this is any one of the dozens of
utilities that do exactly this, and I know that I'm probably a freak and
there's no good reason for you to do something like that. So it's not at all a
feature request. :-) (I'm moving back to Linux full-time in the next couple of
days anyway, so I don't even get to be one of your customers.)

> _I did implement a way to get auto-copy-on-select like Unix terminals do..._

I personally actually don't like that. It's usually harmless, but every once
in a while, I'll be trying to grab a single piece of text, and the window will
scroll for some reason at the same time, and I'll get a bunch of garbage into
the clipboard. That's really not a big deal, except sometimes I'm an idiot and
not paying attention, and I'll try to paste that in another terminal.

To me, it violates the UI rule about not surprising your users. If I had
wanted to copy that chunk, it wouldn't've been any trouble to hit command-c.
But, again, I'm probably way in the minority here.

I really appreciate by the way that MacTerm is still compatible with 10.3.9+.
PPC luddites like me are starting to have a difficult time out there.

Oh! There is one thing I just thought of that would make you heroic. For some
reason, every single Terminal program I've tried so far will auto-scroll the
window when there's new output, and try to scroll down to the bottom-most line
besides. So, say for example I'm going through a bunch of tcpdump output -- I
now have to fight the window I'm in to be able to scan for the stuff I'm
looking for, or to select text. If the user scrolls up or selects some text,
it would be pretty cool to stay right there at that scroll point, and let the
user catch up when they're ready.

I'm doing some terminal work today, so I'll give your app a try and see if I
can offer more useful feedback.

~~~
makecheck
I appreciate the help even if you'll be heading to Linux. (While you're there,
check out "aterm" which I kind of like but had nothing to do with.)

I don't have command-option-arrows (they're used for other things), though the
menu items for next/previous window are available as command-tilde and
command-shift-tilde. So in theory the Keyboard pane in System Preferences can
be used to remap them to any other keys.

I can appreciate the idea of piecing text together, I'm frequently cracking
open temporary "vim" sessions to do that. Would you consider it too much to
rely on a macro for that? Using the existing macro scheme it's straightforward
to do something like remap command-option-V to open a new editor in a new
window.

I agree that auto-Copying selections can sometimes be unexpected, so I left it
as a preference. But should you accidentally dump garbage into a window,
there's even an option to intercept multi-line Pastes.

Thanks for mentioning 10.3.9. :) Yes, that has been increasingly tricky to
pull off, but I figure as long as Apple hasn't made it impossible to support I
can keep it working.

As far as the scroll behavior on new input; I believe I actually am doing what
you'd expect (though only when scrolled back; selecting text has no effect on
it). There is also a way to suspend/resume explicitly, though any terminal can
do that using the appropriate start/stop control sequences.

------
joiguru
I use rxvt-unicode. The 3 things i would love to have is low mem usage, 256
color support, and large scrollback. I love good colorschemes in my vim.

~~~
makecheck
I've implemented 256-color support (if XTerm is requested), and the scrollback
can be set to any size though I am working on some other options to make it
more flexible.

I haven't optimized for memory usage, but that's a good point. I did compare
my launch state against Apple's Terminal using "top", and found that I used
roughly the same real memory size but only 1/3 of the virtual memory. There
could be many reasons for the difference of course.

------
eisbaw
Gnome-terminal is the fastest terminal on Linux, and looks good too!

------
derrida
It has to have the ability for the context of keystrokes to be toggled.
Sometimes I notice that there are conflicts between Emacs key bindings and the
operating system.

~~~
makecheck
I don't notice those conflicts in my implementation, but then again I'm not
using Apple's text view. Every "normal" text field on the Mac (which I believe
at least Apple's Terminal is using) has built-in Emacs-like bindings; I think
that's why you see a conflict.

I do have the concept of toggling context with macros; e.g. you can define up
to 12 actions at a time, mapped to almost any key combinations, and choose
between as many sets of 12 as you want.

I also work around potential key mapping issues by having floating keypad
windows. For example, if for some reason control-A doesn't work from the
keyboard, it's always possible to "click" a button that will produce a
control-A. (This was very useful in the old days in programs like "pine" that
had redefined control-C among other things.)

------
marssaxman
Not really sure what a terminal emulator would do that the Mac OS terminal.app
doesn't do. My wants are not complicated.

------
Jarred
iTerm2 is great, and Terminal is also pretty good.

Make a good terminal UI for Windows. Those don't exist, and the OS-bundled one
is crap.

~~~
juanipis
i use both iterm2 and Terminal only coz Visor (<http://visor.binaryage.com/>)
is too slick.

and yeah, windows terminal makes you feel like ur living in the stoneage.

~~~
makecheck
I've been thinking about adding something like Visor, and I haven't come up
with anything yet.

I've only used Windows (XP) seriously for a few months of work, and I agree
that it felt like the stone age.

As much as I can see the need for something better on Windows, I no longer use
Windows (gladly, too), and I don't own any PCs. Almost all of the hardware
that I have easy access to is using Mac OS X these days.

My code is GPL however; so if someone has the drive to actually produce a
terminal on Windows, they might find mine useful as a reference. After all,
I've implemented fairly complicated things like an XTerm, VT100, VT220, etc.
and a UTF-8 decoder, and you wouldn't want to start those from scratch.

