I'm not affiliated with it, but I've been using the Warp terminal program for a few months now and suspect that if you're interested in this kind of thing, you might like that too.
In short, besides the obvious AI stuff, which works well:
- You can edit the command line as though it's in a GUI program (including with mouse, etc) instead of it being inside the terminal where you need to use different keybindings and no mouse.
- When in a shell, instead of your window being one long stream of text, each command and each output is a discrete area, so it's easier to, say, select the whole output of a command.
Warp also has a cool looking cataloging feature where commands can be bundled up and shared with your co-workers. Seems a good solution for sharing those dark arts folks tend to build up over time.
> Seems a good solution for sharing those dark arts folks tend to build up over time
This is one of the things I most _dislike_ about it. Don't incentivize hording those useful tools in yet-another-silo, get them out into a shared code package!
Fair! I’d not considered that aspect, but you’re right, serializing these into a git repo would be the correct solution here.
I think the integration is important though; I’ve vented plenty of steam at co-workers who don’t look at the COMMANDS.md / README.md / etc in a repo. It being auto imported into their terminal program (with search, autosuggestion, and adjacent documentation) seems a pretty killer offering for teams.
> It being auto imported into their terminal program [...] seems a pretty killer offering for teams.
I'm often pretty torn on recommendations like this - to use another tool to account for coworkers unwillingness to use (or, learn to use) the existing/underlying one. It reminds me of a time that I saw someone singing the praises of a GUI for Git because it allowed them to do things you couldn't do from the CLI "like adding only parts of a file" - to which someone replied simply "`git add -p`".
From an outcome-focused perspective, I suppose any introduced tool or process which "gets the job done better" is desirable, if it comes at zero cost. To me, the "lock-in" that everyone _has_ to use Warp in order to benefit from this shared knowledge is a non-zero cost, and requiring software engineers to know how to push code to a Git repo is not an unreasonable expectation. But if everyone's _already_ enthusiastic to use Warp for other reasons, I suppose my objection is moot.
> (with search, autosuggestion, and adjacent documentation)
adjacent documentation feels like a straw-man - man pages or `my-tool --help` exist for standard scripts! Ditto for search - if GitHub's search lets you down, then `grep searchterm /path/to/my/scripts/directory` still works. Autosuggestion is fair, though - although I do know that it's possible to have tool-specific auto-completes (e.g. https://kubernetes.io/docs/reference/kubectl/generated/kubec...), I'll bet Warp makes it easier than a standard shell does.
In short, besides the obvious AI stuff, which works well:
- You can edit the command line as though it's in a GUI program (including with mouse, etc) instead of it being inside the terminal where you need to use different keybindings and no mouse.
- When in a shell, instead of your window being one long stream of text, each command and each output is a discrete area, so it's easier to, say, select the whole output of a command.