Warp engineer here. Really appreciate your ideas here!
> Warp's more visual completion is super welcome. Does it work with the shell's standard completion scripts?
It does not. But we have completions out of the box for 200 commands.
Warp's input is a text editor instead of the shell input. This means we ended up building completions by hand and soon, via the community. We think this is a better experience because we can provide more in-line documentation.
> Warp's blocks look like a nice step in the right direction. How do they work?
tldr; shell hooks
Most shells provide hooks for before the prompt is rendered (zsh calls this precmd) and before a command is executed (preexec). Using these hooks, we send a custom Device Control String (DCS) from the running session to Warp. Our DCS contains an encoded JSON string that includes metadata about the session that we want to render. Within Warp we can parse the DCS, deserialize the JSON, and create a new block within our data model.
Re: impersonation: that's a good concern we will consider.
> It'd be interesting to further extend blocks with some protocol that allows programs to output within their block using richer elements.
Absolutely! This is definitely in the roadmap. We want rich output like adjustable tables and images. We also want to support a protocol so other CLI programs can use it.
> Likewise, when launching alternate-screen terminal stuff, to allow them to do more with the rectangle than a grid of text.
Yes we are thinking of supporting blocks within tmux, for example.
> And at first glance, looks like it's missing tmux-like features (whether integration with tmux proper like iTerm has or its own thing).
Yes, other than split panes, we do not have tmux-like features. We've begun mocking out what those features could look like. We are thinking of a native window management solution and a native way of saving workspace/session templates.
We are also thinking of what a deeper integration with Tmux might look like.
Meh, I could be into it without them providing a FOSS implementation. Think of Microsoft's language server protocol. It's nice that VS Code is open source, but even if it weren't, we might still be using this protocol with rust-analyzer and neovim. Or any number of older protocols/formats with RFCs that didn't start with good FOSS implementations.
In the case of completion, if you can generate (less rich but still useful) bash/zsh/fish completion scripts from these files, program authors might be happy to use it even in the absence of a fancy terminal.
I'm wondering if the solution for the block separation could be to have separate tty (or pty?) for each block. I guess that wouldn't work too well with existing shells though
That might be interesting for supporting multiple blocks running at once without confusion, as an update to the classic shell job control. Highlighting stdout vs stderr differently, too.
Another dimension to consider is the possibility of nested blocks: subshells, ssh, programs with their own REPL, etc.
That is how I thought it worked first. That each pty executed its own shell instance and passed their environment and current working directory between them. Perhaps that would be a very naive approach that couldn't work in practice
> Warp's more visual completion is super welcome. Does it work with the shell's standard completion scripts?
It does not. But we have completions out of the box for 200 commands.
Warp's input is a text editor instead of the shell input. This means we ended up building completions by hand and soon, via the community. We think this is a better experience because we can provide more in-line documentation.
> Warp's blocks look like a nice step in the right direction. How do they work?
tldr; shell hooks
Most shells provide hooks for before the prompt is rendered (zsh calls this precmd) and before a command is executed (preexec). Using these hooks, we send a custom Device Control String (DCS) from the running session to Warp. Our DCS contains an encoded JSON string that includes metadata about the session that we want to render. Within Warp we can parse the DCS, deserialize the JSON, and create a new block within our data model.
Re: impersonation: that's a good concern we will consider.
> It'd be interesting to further extend blocks with some protocol that allows programs to output within their block using richer elements.
Absolutely! This is definitely in the roadmap. We want rich output like adjustable tables and images. We also want to support a protocol so other CLI programs can use it.
> Likewise, when launching alternate-screen terminal stuff, to allow them to do more with the rectangle than a grid of text.
Yes we are thinking of supporting blocks within tmux, for example.
> And at first glance, looks like it's missing tmux-like features (whether integration with tmux proper like iTerm has or its own thing).
Yes, other than split panes, we do not have tmux-like features. We've begun mocking out what those features could look like. We are thinking of a native window management solution and a native way of saving workspace/session templates.
We are also thinking of what a deeper integration with Tmux might look like.