[EpicEng]

I'm not sure I understand; if you don't care about the output then send it to /dev/null. If you do care then pipe it to an editor. A terminal is not a text editor (I mean, I suppose it could be, but that seems like a rather large scope change.)

[terminal-survey]

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.

[EpicEng]

I don't know that make is a good example here. This is a tool you use constantly, so I imagine you'd know to pipe std err if you wanted its output. We seem to be talking about turning the terminal into a full blown editor (when we already have editors...) to satisfy a rather limited use case of 'oops, guess I have to run that again."

But hey; your time to spend :)

[khedoros1]

> We seem to be talking about turning the terminal into a full blown editor (when we already have editors...) to satisfy a rather limited use case of 'oops, guess I have to run that again."

That seems like an incredibly common use case to me. It's common for a command to have a lot more output than I originally expected, and when it happens, I usually want to examine that output in detail. It would be great to retroactively be able to open captured output in a text editor, dump it to a file, pipe it to another tool, or collapse it.

I don't really want to edit the output in the terminal, but it would be great to be able to say "oops, do X with stdout from that last command, and do Y with stderr".

[afarrell]

FWIW, I also find myself wanting this.

[UncleMeat]

Sometimes you forget. Or sometimes a command generates an unexpectedly large amount of output. This is a tool that I use every day. Usability should be a priority. Even if there is a more complex way of doing something, it is better if there is a simple way.