Ask HN: What do you look for in a terminal?
6 comments
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.
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.
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.
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.
> 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.
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.
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.
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.
OK, so I tried it out, and have immediately bumped into two things on it, one of which is kind of a show-stopper.
The first is kind of a minor nit, but when launching MacTerm for the first time, I get prompted to choose a terminal, and the options don't immediately make sense. Choosing "Shell" at random caused the terminal window to seemingly appear and then disappear; choosing "Log-In Shell" at random did the same thing, until I found it under the File menu ... I think? When re-launching the app, the behavior seems to have changed. At least, I can't get it to do the appear-and-disappear thing now; instead, the first two options just give me a blank window.
I much prefer being presented with a ready-to-go terminal session in a window without having to answer any questions first or go searching for the session I just started.
But maybe you set it up that way for a good reason and I just don't know it.
The show-stopper though is the font rendering. Here's a screenshot of my desktop, with full-screen iTerm2 in the background and MacTerm in the foreground: http://i.imgur.com/5D1z2.png
I've set up both of those apps to use the same font (Monaco) at the same point size (12), and the rendering looks a lot different. I can stare at iTerm all day and not want to gouge out my eyes afterward; I don't think I could spend much time in MacTerm without hating life. I didn't see an option in the preferences for anti-aliasing; did I miss it?
Since a terminal window does nothing but assault the viewer all day with text, doing the text rendering really really well is a great way to make your app stand out. Prepackaging a default mono-spaced font like Consolas or Panic Sans (not likely on that one, but maybe worth a shot?) would help a lot, because Monaco is really not the best font out there for programmers.
Stuff I liked right away: I really liked that you include the scroll bar in your full screen mode, but none of the other window chrome. Nice! That's something that iTerm2 gets wrong. I want the scroll bar, but none of the other stuff, in full-screen mode.
Hope this helps.
The first is kind of a minor nit, but when launching MacTerm for the first time, I get prompted to choose a terminal, and the options don't immediately make sense. Choosing "Shell" at random caused the terminal window to seemingly appear and then disappear; choosing "Log-In Shell" at random did the same thing, until I found it under the File menu ... I think? When re-launching the app, the behavior seems to have changed. At least, I can't get it to do the appear-and-disappear thing now; instead, the first two options just give me a blank window.
I much prefer being presented with a ready-to-go terminal session in a window without having to answer any questions first or go searching for the session I just started.
But maybe you set it up that way for a good reason and I just don't know it.
The show-stopper though is the font rendering. Here's a screenshot of my desktop, with full-screen iTerm2 in the background and MacTerm in the foreground: http://i.imgur.com/5D1z2.png
I've set up both of those apps to use the same font (Monaco) at the same point size (12), and the rendering looks a lot different. I can stare at iTerm all day and not want to gouge out my eyes afterward; I don't think I could spend much time in MacTerm without hating life. I didn't see an option in the preferences for anti-aliasing; did I miss it?
Since a terminal window does nothing but assault the viewer all day with text, doing the text rendering really really well is a great way to make your app stand out. Prepackaging a default mono-spaced font like Consolas or Panic Sans (not likely on that one, but maybe worth a shot?) would help a lot, because Monaco is really not the best font out there for programmers.
Stuff I liked right away: I really liked that you include the scroll bar in your full screen mode, but none of the other window chrome. Nice! That's something that iTerm2 gets wrong. I want the scroll bar, but none of the other stuff, in full-screen mode.
Hope this helps.
Thanks for all the comments!
The startup behavior might be slightly historical, it used to be a remote-only shell in the Classic Mac days and didn't really have a local shell. Back then there was always something needed (host name, whatever), and technically it is still possible to start sessions that way. But good point...I may change the built-in default.
In any case, the startup behavior is controlled by the contents of the Default Workspace (in Preferences -> Workspaces). So you can turn off all windows, or spawn certain windows that contain whatever you want.
EDIT: I've identified what caused the "appear and disappear" behavior you described. You can download the latest version from here and it will be fixed: http://macterm.net/updates/daily.html
Thanks for the font info. I'm not sure (as a free GPL program) how to package a font, but if I can find one that's compatible and OK to include I probably will. I've even tried Consolas myself. As for the rendering, that is very close to the top of my list and is quite complicated. As I mentioned earlier, the code has its roots in Classic and I'm not relying on modern drawing code completely. That is set to change, but it's slow work. :) Unicode rendering has the same problem; although the buffer and decoder work perfectly, and you can copy/paste/drag/print any Unicode, the terminal can't display every character and it's because the drawing code is too old.
I'm glad you like how Full Screen works. Also note there's a bunch of stuff in Preferences that you can tweak for that mode.
The startup behavior might be slightly historical, it used to be a remote-only shell in the Classic Mac days and didn't really have a local shell. Back then there was always something needed (host name, whatever), and technically it is still possible to start sessions that way. But good point...I may change the built-in default.
In any case, the startup behavior is controlled by the contents of the Default Workspace (in Preferences -> Workspaces). So you can turn off all windows, or spawn certain windows that contain whatever you want.
EDIT: I've identified what caused the "appear and disappear" behavior you described. You can download the latest version from here and it will be fixed: http://macterm.net/updates/daily.html
Thanks for the font info. I'm not sure (as a free GPL program) how to package a font, but if I can find one that's compatible and OK to include I probably will. I've even tried Consolas myself. As for the rendering, that is very close to the top of my list and is quite complicated. As I mentioned earlier, the code has its roots in Classic and I'm not relying on modern drawing code completely. That is set to change, but it's slow work. :) Unicode rendering has the same problem; although the buffer and decoder work perfectly, and you can copy/paste/drag/print any Unicode, the terminal can't display every character and it's because the drawing code is too old.
I'm glad you like how Full Screen works. Also note there's a bunch of stuff in Preferences that you can tweak for that mode.
I came back here to see if I could figure out the appear-and-disappear problem, and you've already fixed it. Nice work. :-)
Glad to help. :) Let me know if you need anything else.
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.
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.
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.
Gnome-terminal is the fastest terminal on Linux, and looks good too!
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.
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.)
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.)
Not really sure what a terminal emulator would do that the Mac OS terminal.app doesn't do. My wants are not complicated.
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.
Make a good terminal UI for Windows. Those don't exist, and the OS-bundled one is crap.
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.
and yeah, windows terminal makes you feel like ur living in the stoneage.
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.
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.
I develop a Mac terminal emulator, and a friend once asked me why. 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?