[waqf]

Fix scrollback. Sometimes I run a command and it has 50,000 lines of output. Either I don't care about the output — in which case I should be able to click to fold it up and be able to see my history before that one command — or I do care about it, in which case I want every scroll, search and export operation that a full-fledged document editor would have.

In either case, UI latency shouldn't suffer, scroll bars shouldn't become unusable, my scrollback history before that one command shouldn't be thrown away — Mathematica notebook style, as another commentator suggests, might work well here.

[JdeBP]

Crank up NeoVIM. Run :terminal . Use those commands and break out of terminal mode, possibly with a long running command still running, with the mouse or with Control+\ Control+N . Explore the searchability and the use of :set scrollback .

Is that approximately the sort of thing that you are looking for?

[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.