Suggestion: structured commands with renderers

[mauricioszabo]

I know this can span to multiple features and maybe it's a bit complicated (I'm willing to help work on it if it sounds interesting for the team), but I had an idea:

Suppose that instead of running (sh-str ls) and getting a string, we could run something like (ls) (we can define some common-based commands) and make then return valid EDN. For example, (ls) could return something like a vector of maps containing the filename, file attributes, etc. Together with this EDN, we could add metadata like ^{:render/as <some-fn>}. The idea is that the object should be sent to this render function, and then displayed on the terminal.

The interesting part of this idea would be to allow people to change their render functions (someone may want to render ls results as richer data, paginate, add colors, etc) and also to allow people to program their shells better (because (ls) is now returning structured data, we can pipe to sort-by, vec, etc).

I know it's not a simple solution, but it would be similar to what Notespace (https://github.com/scicloj/notespace) is trying to do.

[dundalek]

Hey Mauricio, this is something I am very interested in. I showed a possible workflow in my clojureD talk last year. For the demo I created a simple wrapper for builtins from Nushell. It would be great to have Clojure implementation for these, because it could become even more powerful than what Nushell has. I did not find time to work on this yet, so I would be very glad if you are interested to work on this.

I think these implementations could live as separate libraries and then we would just make a tight integration with closh. The reason for separate libraries is to make them also usable in tools like Reveal and Portal which are also very cool. I follow their work and am excited what they will come up with. I think there will be definitely opportunities for synergies. (BTW it would be super cool to try to run closh inside Reveal/Portal to leverage them for showing structured output.)

Some other notes:

• We can bind commands with (defcmd ls some-lib/ls) where some-lib/ls is a plain function. That way one can type just ls instead of (ls).
• Besides render function the commands should also provide default print function. ls alone would render the UI. But when used in pipeline it would get printed as string/lines so that you could pipe it to unix commands like ls | sed ....
• We should try to used datafy+nav whenever possible. That way if you list files you could for example navigate down into directories.

[awb99]

Great idea Mauricio!

[dundalek]

Another project I discovered recently is https://github.com/kellyjonbrazil/jc which parses output of many commands into JSON, which could be very useful. With it we could get the command output as data and try those data-driven UI experiments.