3 ms·
Regarding the shell != terminal issue that is mentioned in several other comments... You've named a valid reason to blur the shell/terminal distinction. Nice.
by daveloyall 10y ago
Regarding the shell != terminal issue that is mentioned in several other comments... You've named a valid reason to blur the shell/terminal distinction. Nice.
Another would be: the ability to manipulate streams (or whatever you'd like to call the content that flows through pipes). As in, replay a stream into some new process without re-executing the original.
Another would be to fold terminal output.
Removing the shell/terminal distinction opens a door to a world of possibilities. But, the door closes behind you!
- sime2009 10y ago> Another would be: the ability to manipulate streams (or whatever you'd like to call the content that flows through pipes). As in, replay a stream into some new process without re-executing the original. My terminal (https://github.com/sedwards2009/extraterm https://github.com/sedwards2009/extraterm) can more or less do that now: https://raw.githubusercontent.com/sedwards2009/extraterm/master/docs/from_command.gif https://raw.githubusercontent.com/sedwards2009/extraterm/mas... > Another would be to fold terminal output. I did have something like that, but had to disable it. That feature will make a reappearance sometime as I want it for things like automatically collapsing command (e.g. compiler) output if terminals successfully. I only need to see the output of failed builds, for example.