Looks like people more and more people are realising that the next usability iteration on terminal is seeing the result as you type.
More applications keep implementing this workflow, probably shells will implement it in a general fashion in years to come.
Some years ago I hacked together a small curses program that accepted a command with a placeholder and presented a prompt that would re-run the command with the new input on each krypress. I never published it because it was very hacky and quite dangerous if you’re not careful.
This is very true for text editors as well IMO, which is why I use kakoune which shows the incremental results as you preform complex combinations of actions or select based on a regex.
the problem is with process spawning overhead in my opinion – doing it for every keystroke needs debouncing and at that point the UI starts to lag. If apps have native support for it they can do something more efficient
I don’t mean that the textbox itself becomes unresponsive but rather that the preview will have to endure the cost of process startup and starting from scratch and depending on the operation that is previewed that can be expensive. I have had this experience with the exact ag example… ag takes time to search things, but depending on previous preview it may not have to search the entire space again.
st is very good at dampening the impact but things can be better with a different architecture
I’m interested to see what kinds of things Jupyter might inspire in shells. The notebook workflow mostly fits tasks with requirements halfway between an interactive shell and an executable file (as in exploratory data analysis and the like), but the concept has already made its way over to the text editor side (in VSCode you can use a magic comment command to delineate and execute individual code cells within a file to view output while still editing, as if it were a notebook). I wonder what that might conceptually look like if taken to the shell side instead of the editor side.
I’ve always flt like there should be this interface for all the “general” CLI tools, especially with piping. I’ve never figured out exactly what the interface should be (and there’s a bit of a persistence/workflow thing involved) but whoever figures the right one will be doing a great service to all of CLI-land
Doesn’t seem too inviting for people not using Haskell in other areas… a case could be made that a person familiar with Python likely would use python -c for this too
Honestly, this should be part of
jqitself, eg.jq -i.Looks like people more and more people are realising that the next usability iteration on terminal is seeing the result as you type. More applications keep implementing this workflow, probably shells will implement it in a general fashion in years to come.
Some years ago I hacked together a small curses program that accepted a command with a placeholder and presented a prompt that would re-run the command with the new input on each krypress. I never published it because it was very hacky and quite dangerous if you’re not careful.
This is very true for text editors as well IMO, which is why I use kakoune which shows the incremental results as you preform complex combinations of actions or select based on a regex.
I think you can sort of do this with https://github.com/lotabout/skim#as-interactive-interface – perhaps even integrate that into the shell itself
fzf may have a similar option
the problem is with process spawning overhead in my opinion – doing it for every keystroke needs debouncing and at that point the UI starts to lag. If apps have native support for it they can do something more efficient
Yes. It did essentially that that you linked. The UI doesn’t need to get unresponsive, text input is decoupled from external process execution.
I don’t mean that the textbox itself becomes unresponsive but rather that the preview will have to endure the cost of process startup and starting from scratch and depending on the operation that is previewed that can be expensive. I have had this experience with the exact ag example… ag takes time to search things, but depending on previous preview it may not have to search the entire space again.
st is very good at dampening the impact but things can be better with a different architecture
I’m interested to see what kinds of things Jupyter might inspire in shells. The notebook workflow mostly fits tasks with requirements halfway between an interactive shell and an executable file (as in exploratory data analysis and the like), but the concept has already made its way over to the text editor side (in VSCode you can use a magic comment command to delineate and execute individual code cells within a file to view output while still editing, as if it were a notebook). I wonder what that might conceptually look like if taken to the shell side instead of the editor side.
Aren’t you describing fish? :)
It’s hard to overstate just how helpful an interactive exploration tool like this can be.
As others have mentioned, fzf can be used to improvise something similar:
You can use this trick to make an interactive exploration tool for any jq-like utility – sed and awk work well, for example.
A similar tool: https://github.com/antonmedv/fx
Yet another good example of product/tool advertisements on Lobste.rs (one of many by /u/skuzzymiglet to be honest).
Find the tag discussion here: https://lobste.rs/s/r6xtpo/tag_request_tool_product
Very similar thing for AWS’ Jmespath exists for some time, called
jpterm: https://github.com/jmespath/jmespath.terminalI was using it a lot when I was managing AWS stuff.
Good to see a jq version.
I’ve always flt like there should be this interface for all the “general” CLI tools, especially with piping. I’ve never figured out exactly what the interface should be (and there’s a bit of a persistence/workflow thing involved) but whoever figures the right one will be doing a great service to all of CLI-land
https://twitter.com/puffnfresh/status/1352203388759453697
I use Haskell lens instead of jq, jq, xmlstarlet, etc. I’d love to see this with an integration to GHCi.
For anybody curious, I had to look a bit but found https://github.com/danidiaz/lens-aeson-examples/blob/master/src/Data/Aeson/Lens/Examples.hs#L118
Doesn’t seem too inviting for people not using Haskell in other areas… a case could be made that a person familiar with Python likely would use
python -cfor this tooGreat. To get something similar (manually grokking a ginormous json blob) I was using irb, this is awesome. Thanks!
Prior art: simeji/jid: json incremental digger