4 ms·

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 f

by waqf 9y ago

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.

EpicEng 9y ago
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 9y ago
  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.
  - deleted 9y ago
    [deleted]
  - EpicEng 9y ago
    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 9y ago
      > 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 9y ago
        FWIW, I also find myself wanting this.
- UncleMeat 9y ago
  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.
JdeBP 9y ago
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?

by waqf 9y ago

EpicEng 9y ago

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 9y ago
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.
- deleted 9y ago
  [deleted]
- EpicEng 9y ago
  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 9y ago
    > 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 9y ago
      FWIW, I also find myself wanting this.
UncleMeat 9y ago
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.

JdeBP 9y ago

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?