7 ms·
Ask HN: What do you look for in a terminal?
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?
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?
- thaumaturgy 15y agoI've used iTerm2 (http://www.iterm2.com/ 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 15y agoI 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 15y ago> 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 15y agoI 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.
- Jarred 15y agoiTerm2 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 15y agoi use both iterm2 and Terminal only coz Visor (http://visor.binaryage.com/ http://visor.binaryage.com/) is too slick. and yeah, windows terminal makes you feel like ur living in the stoneage.
- makecheck 15y agoI'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.
- derrida 15y agoIt 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 15y agoI 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.)
- eisbaw 15y agoGnome-terminal is the fastest terminal on Linux, and looks good too!
- marssaxman 15y agoNot really sure what a terminal emulator would do that the Mac OS terminal.app doesn't do. My wants are not complicated.
- joiguru 15y agoI 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 15y agoI'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.