terminal-survey

> I would love to use one of those fancy graphical terms that comes up on HN every now and then

One of these (Black Screen) is among the many inspirations with which we started.

> Any attempt to improve the terminal has to be something that I could switch to on a whim and then gradually grow into.

Backwards-compatibility is a hard requirement for us because of that. And oh boy, it causes a lot of pain.

> I've essentially duplicated the evolution of HTML+JS webapps

This is a huge fear of mine. We need to find a way of opening the GUI can-of-worms without ending up with terminals that are as bloated as contemporary web browsers.

As soon as the project is at a point where we feel comfortable showing it to a wider audience, we'll make a proper announcement and post it to HN (among other places).

You mean that it should scroll in the opposite direction?

I think the problem is that you only know if you care about the output after the fact. For example, if "make" runs through, I usually don't care about the output. But if "make" fails, then I want to read the error messages.

As I said somewhere else, we have a concrete solution in mind for implementing folding as GP describes.

We are currently doing most of the work offline, so it's difficult to collaborate with a far-reaching network of contributors at this point. However, if you drop me a note at < 34c3-terminal-survey at posteo dot de >, I can put you on the list of people to ping once we have something that can be put in front of more eyes.

Yes, it would be nice if reflowing became more common. We are not sure if our spec requires the terminal to support reflowing (because of the resource usage implications), but the terminal must at least be able to announce whether it does reflowing (and/or word wrapping).

> i've got ~20 bashes open in various tmux configurations. the amount of times i lost command history is infuriating (e.g. due to reboot or whatever).

zsh does (has an option to) commit commands to the history file immediately when you execute the command. Makes me hate bash even more when I have to use it occasionally on a server.

Hi everyone, thanks a lot for the responses. Keep them coming!

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.

Oh yes. We want to have an API where clients (i.e. programs running in the terminal) can receive actual key/pointer/touch events if they choose to. The terminal may retain control over a few crucial keysequences (similar to how Ctrl-Alt-Del is always handled by the OS on Windows), but it has to inform the client about that.

We already have a solution for this sketched out on paper (not in writing or code yet, though). The idea is that the shell can split the terminal into "frames", where each frame acts as its own terminal. The shell would then use one frame per command prompt, and one frame per command (for its input and output). The stdin/stdout that is given to the command is restricted to that particular frame. It can then write text into that frame and move the cursor around inside it, but cannot break out of the frame, so e.g. it cannot overwrite the output of the previous command.

And once you have these frames, you can give them some useful properties: For example, the shell can fold them, or apply styling hints to them (e.g. so that a command with non-zero exit code can be highlighted with a red border or similar).

With frames, you can also have multiple commands running in parallel. For example, wget could signal to the shell that it will run for a while longer, but does not require user interaction, so the shell can allocate the next frame below the frame where wget is still running, and offer the next command prompt.

It also means that fullscreen programs do not need to block everything: vim may be running inside a frame that is set to the full window size, but you can just move the keyboard focus out of this frame and scroll upwards to review the output of a previous command while vim continues to run down below.

> At first I would state one curious fact: [...]

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

> "cat" could never work of course

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.

Our draft already contains a command for "set terminal into ignore-escape-sequences mode". I added that last week when someone showed how to hide malicious code in "git diff" by using specifically crafted control sequences.