4 ms·

Like others here, I'm leery of replacing my terminal with a VC-backed, maybe open-sourced eventually product, and a bit annoyed it claimed a name already in use

Like others here, I'm leery of replacing my terminal with a VC-backed, maybe open-sourced eventually product, and a bit annoyed it claimed a name already in use in the Rust world. But...it is exciting to see someone reimagining the terminal a bit. People frequently talk about wanting a better GUI interaction model for everyone, but the actual ideas to improve it seem to be missing, I think because the desktop status quo is really not that bad for low-learning curve systems. (In fact, I think many of the changes in the name of desktop/mobile convergence have been for the worse.) I'm way more interested in the idea of creating a hybrid text/graphic command interface for programmers. There's a much better interface waiting for someone with the vision and (more importantly) ability to create an ecosystem around it. Some ideas: * Warp's more visual completion is super welcome. Does it work with the shell's standard completion scripts? * Warp's blocks look like a nice step in the right direction. How do they work? I'd guess it's ANSI codes like iTerm uses to distinguish the ends of commands, although that has the downside that a broken/hostile command can impersonate the shell saying the command has ended. It'd be nice to work out some compatible yet more robust protocol. (Maybe the shell takes responsibility for piping subcommand's output through it and filtering, or maybe something else.) * It'd be interesting to further extend blocks with some protocol that allows programs to output within their block using richer elements: non-monotype fonts, adjustable tables, etc. A little like a Jupyter notebook, maybe. Even better if it works with some richer way for programs to pipe information to each other. * Likewise, when launching alternate-screen terminal stuff, to allow them to do more with the rectangle than a grid of text. Closer to embedding an arbitrary cross-platform network-transparent GUI, launched from the shell, occupying its rectangle. * And at first glance, looks like it's missing tmux-like features (whether integration with tmux proper like iTerm has or its own thing). I'd want that in any richer terminal app—most of my work in terminals is on remote machines, often over flaky network connections.

michlim 5y ago
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.
- wildmanx 5y ago
  > This means we ended up building completions by hand and soon, via the community. You like people to contribute for free ("build a community") but refuse to give them an actual FOSS client. This is bound to fail. There are ways to make this go both ways though, and I hope you'll make them work once you are a bit further along in your journey. Exciting project!
  - wodenokoto 5y ago
    > You like people to contribute for free ("build a community") but refuse to give them an actual FOSS client. This is bound to fail. Sublime text has a pretty active community that builds and shares extensions. Why not warp?
    - ushakov 5y ago
      Sublime is selling a product that users can purchase and own Warp is owned by venture capitalists
  - scottlamb 5y ago
    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.
    - Siira 5y ago
      There exists multiple fully functional FOSS LSP clients. The semi-proprietariness of VS Code does not doom LSP. The documentation people would contribute to Warp though are unlikely to have any popular FOSS clients.
- 5y ago
russellendicott 5y ago
I'm working on a terminal browser of sorts that is designed to browse terminal user interfaces served by servers. The idea is that no mouse input is supported and servers specify keyStrokes for links. It starts from a protobuf specification optimized for sending components over gRPC in a pageRequest/pageResponse manner. In order to promote the idea I've been spending most of the time writing a client in Go. I think it has enough functionality that I can start writing servers that really showcase the capabilities.
- qudat 5y ago
  This sounds like ssh apps via https://charm.sh https://charm.sh
  - russellendicott 5y ago
    Yes. Thanks for this. This is very very similar to what I'm trying to do. I guess more like the subproject https://github.com/charmbracelet/wish https://github.com/charmbracelet/wish than anything. I suppose the difference is that I like the idea of being able to link to other servers and keep a contextual menu bar telling the user where they are. Also, in corporate environments SSH is often locked down because of what it could potentially do. This would be nice as it would be sandboxed to only what the client/server are coded to do. Thanks for the link, this gives me some things to think about.
    - qudat 5y ago
      FWIW, I think ssh apps or something similar could be a very powerful paradigm for people who live in the terminal and a diversity of ideas here would be welcome.

michlim 5y ago

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.

wildmanx 5y ago
> This means we ended up building completions by hand and soon, via the community. You like people to contribute for free ("build a community") but refuse to give them an actual FOSS client. This is bound to fail. There are ways to make this go both ways though, and I hope you'll make them work once you are a bit further along in your journey. Exciting project!
- wodenokoto 5y ago
  > You like people to contribute for free ("build a community") but refuse to give them an actual FOSS client. This is bound to fail. Sublime text has a pretty active community that builds and shares extensions. Why not warp?
  - ushakov 5y ago
    Sublime is selling a product that users can purchase and own Warp is owned by venture capitalists
- scottlamb 5y ago
  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.
  - Siira 5y ago
    There exists multiple fully functional FOSS LSP clients. The semi-proprietariness of VS Code does not doom LSP. The documentation people would contribute to Warp though are unlikely to have any popular FOSS clients.
5y ago

russellendicott 5y ago

I'm working on a terminal browser of sorts that is designed to browse terminal user interfaces served by servers. The idea is that no mouse input is supported and servers specify keyStrokes for links. It starts from a protobuf specification optimized for sending components over gRPC in a pageRequest/pageResponse manner. In order to promote the idea I've been spending most of the time writing a client in Go. I think it has enough functionality that I can start writing servers that really showcase the capabilities.

qudat 5y ago
This sounds like ssh apps via https://charm.sh https://charm.sh
- russellendicott 5y ago
  Yes. Thanks for this. This is very very similar to what I'm trying to do. I guess more like the subproject https://github.com/charmbracelet/wish https://github.com/charmbracelet/wish than anything. I suppose the difference is that I like the idea of being able to link to other servers and keep a contextual menu bar telling the user where they are. Also, in corporate environments SSH is often locked down because of what it could potentially do. This would be nice as it would be sandboxed to only what the client/server are coded to do. Thanks for the link, this gives me some things to think about.
  - qudat 5y ago
    FWIW, I think ssh apps or something similar could be a very powerful paradigm for people who live in the terminal and a diversity of ideas here would be welcome.