Most people here probably use terminals / CLIs quite often and like them for their conceptual simplicity: Send a command -> Receive a response. I'm thinking about improving CLIs while keeping what I like about them. One thing I'd like to improve is interactivity in the output. Different use cases require different levels of detail and currently, there's no way to change the level of detail once the result of a command is printed. For example, a lot of commands include

--verbose

options that perform the same action, but print additional output. So what if you could interactively decide what information to show in the output? This would allow more flexible / readable output and wouldn't require re-running commands to get additional information. In the tweet below, I mocked a simple example where a stack trace is hidden by default, but can be shown when needed. What do you think of this small idea? https://twitter.com/FKohlgrueber/status/1293865745420615680

I like it, but what's the next step past mock? Ship terminal+shell?

you might be interested in • xiki () • hyper • nushell

@Kartik Agaram My main intention was to get the idea out and gather feedback. I'm currently not planning to actually implement this. Shells and terminals are a rabbit hole I don't want to get into right now. If I were to implement it though, I'd probably take the chance to rethink terminal interfaces from the ground up. Interactivity, rich formatting, multimedia content, terminal-program-communication, etc., I feel like there's still a lot of unused potential. And most importantly, I'd replace all the old stuff like ANSI escapes,

\r

, etc. with portable and clean 21th-century interfaces.

Mocks are great for decision making. But only if you're planning on doing something based on the feedback. I think I'm just frustrated because I have lots of plans for Mu in this vein, but I HAVE NO HANDS. Stuck with RSI.

Oh, sorry to hear that. I wish you all the best. What are your ideas regarding this in Mu? Another reason for me to do these small demonstrations is to show others that even things that have been as stable as terminals still can be improved.

Oh you know I agree with that 🙂

I actually really like using emacs' eshell for some weird output shenanigans. Because it internally uses buffers for every pipe (doesn't have real pipes) you can go back and forth between the intermediate buffers it creates, cat them, etc. This also looks like a tree editor direction potentially as well, output trees of info, and then have some numbering for previous trees (like lisp repls with $1, $2, $3 backwards etc)

I love the idea of structured input and output for everything. If —help had a sufficiently structured representation, could we auto generate UIs for CLI tools?

yes! nushell does the beginning of that, as does xiki. reminds me of naked objects

This feature would be quite useful in the REPL for my own language project. Here are some other features I need: • Animated text. If you type

time

(which is a numeric expression), then you should see an animated floating point number that counts up, measuring the number of seconds since the command was typed. • Colour swatches. If you type

red

, which is a Colour expression, you should see a colour swatch, in full 24 bit RGB. • Animated 3D shapes. • Visualizations of data structures (eg, lists and records), where data structure elements can be animated numbers, colour swatches, or 3D animated shapes. I doubt I can find off-the-shelf tech that does everything I need, so I expect I'll need to implement this more or less from scratch. ☹️

My plan for a better shell environment (purely theoretical, I have no time left for such pleasures at the moment) would be to start with @Tudor Girba's GToolkit (https://gtoolkit.com/) and implement a playground plugin for running shell commands, capturing the output in a command-specific object that does some basic parsing. It would then be a small job to add customized views on the parsed output - small enough that you could do it on the spot while working on a specific problem. I actually expect the implementation of this idea to be a small project. The big one is providing enough output parsers for popular CLI tools to make it practically useful.

Indeed 🙂