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.