Ask HN: What do you love/hate about terminals? Would you change them?

We have an idea in that direction, where each program in a pipeline can optionally specify a file type, and the last file type hint in the pipeline determines how the stdout is rendered. So if you have "cat image.jpg", then "cat" can indicate a file type of image/jpg, causing stdout to be interpreted as an image. But if you have "cat image.jpg | grep foo" (just making something up here), then grep can indicate a file type of application/octet-stream because it cannot guarantee what the file type is.

The tricky part, from what I can see, is explaining the pipeline topology to the terminal, so that it knows that "grep" comes after "cat", even though command parsing happens in the shell only. That's still a big unknown. A previous project in this area (TermKit) mandated that applications specify a "Content-Type" header (like in HTTP) in their stdout, but that would break most existing programs, so it's not an option for us.

That part is so nicely said I might just steal it for our manifesto. :)

As mentioned in some of my replies, we have already considered some of the things that you mentioned (and incorporated them in our design), but your responses show that there is still a lot more to consider.

The lack of distraction, the information density, the ability to integrate command line tools into my workflow (yes, I have "selected text is copied to the clipboard" enabled).

> What do you hate about terminals?

How slow the modern terminal is to transfer inputs and paint responses. I like a lot about how iTerm2 works (its integration with tmux and sensible keybinds), but dislike the latency even after all the recent improvements to latency.

A much more minor gripe, but I spend a lot of time working on laptops; acknowledging the lack of a middle mouse button (yes, I hate it too) as a reality for most people's interactions with the terminal would be nice.

> If you had to build one from scratch, how would you do it?

First, I would "borrow" heavily from iTerm2 - its customizability and easy defaults.

Second, I would "borrow" from the web browser rendering engines out there. Make it simple for programs to either not care about their output at all and let it look and and act sensibly (paragraph breaks, reflowing around spaces, easy tables, etc), or to define a minimum amount of "styling" to create reasonable outputs (right justifying text, centering, maximum/minimum width, etc), or have absolute control over the positioning of every item with low level feedback about the terminal.

This would have to be done in addition to a backwards-compatible escape-sequence method of placing characters, of course, and couldn't be the default, but simply making it available for new programs would be a great start. Creating libraries for such interactions would be even better.

There is a lot of history in the terminal; it's time to learn from it and plan for a future beyond ASCII.