1. 37

  2. 15

    The post says performance is a key requirement, but never once mentions the word “latency”, which is what actually matters in a terminal. fps is completely irrelevant since a blur of text is totally unusable anyway, so you lose nothing by just discarding some of the display. But a terminal that doesn’t respond swiftly to user input is very frustrating compared to one that does.

    1. 5

      It’s not completely irrelevant. I appreciate that even rxvt-unicode can, as I’ve found out, do 60 FPS, since I got to have a fairly responsive spectrum visualiser (although going that high imposes a high load on the X server). It’s in no way a blur—60 FPS is over 16 ms, even the slow panels for photo editing can do that.

      1. 2

        I agree that latency is the most important performance metric for a terminal (specifically upper percentile latency, since a terminal with good best case latency will still feel sluggish if the tails are long).

        It’s also good to know that a terminal is capable of processing updates quickly; a terminal that has good round trip latency (from keyboard input to a character being displayed) can still feel sluggish if I cat a 64KB text file and don’t get a terminal prompt back for many seconds.

        1. 1

          Oh of course, that’s part of the responsiveness. But you don’t have to actually render to achieve that… in fact, insisting on actually rendering everything might even be harmful depending on how you do it. Input responsiveness is still what’s actually important: if you ctrl+c in the middle of it, that should happen instantly.

          My terminal vs xterm for example, doing the same thing: cat mylib/*.d, 192,000 lines of code being dumped. My terminal does it in 1.5 seconds, with ctrl+c being instant at any point in it. xterm does it in 4 seconds. My code actually renders an individual frame more slowly than xterm… but xterm tries to render it all, so it wastes my time showing a blur of text. Mine just detects that it is spammed output and only actually draws a few representative frames. It redraws periodically just to indicate to me that it is still working, but it doesn’t waste time drawing every detail that are impossible to see anyway. (I concede there might be exceptions where you’re doing like an ascii art animation in the terminal, where my approach is probably sub-optimal, but I’ve never seen it relevant myself)

          rxvt does the same thing in 0.2 seconds, so they do an even better job :) I’m not sure if they just frame drop too or what though, they could legitimately be much faster.

          But anyway I guess my main point is you can afford to drop a lot of frames and deal with a slow render, but you can’t afford to be slow in input processing at all. You wanna actively respond to the user in single-digit milliseconds, but that response doesn’t necessarily mean “re-render all the lines”.

      2. 20

        Confusing naming. There’s already a rust project called warp, but it’s a web framework.

        1. 14

          Funny story: Warp (the terminal emulator) is actually listing warp (the web framework) as a dependency: https://github.com/warpdotdev/warp#open-source-dependencies

          1. 3

            What does God need with a Starship^W^W^W^W^Wa terminal need a web framework for?

            1. 3

              How else are you going to make a GUI? Surely you’re not suggesting something as silly as, say, using a GUI toolkit, the way they did in the stone age!

              1. 1

                I’d love to know as well but as of now Warp (the terminal emulator) is closed beta.

                1. 1

                  @fasterthanlime has a nice video on why would you ever want to use a web browser for a random program’s GUI.

                  1. 1

                    I appreciate the effort, but you’ve highlighted another generational difference: using a video to express a point that could hopefully, succinctly be made in the space of a few paragraphs, without requiring people to look at your face for ten minutes :)

                2. 2

                  I assume that’s for the shared editing feature.

                  1. 10

                    Not to mention OS/2 Warp!

                    1. 5

                      Not to mention the good ol’ Warp drive

                      1. 10

                        I’m worried I’ll confuse it with the original warp lines controlled by the original punch cards.

                  2. 2

                    And OS/2 Warp.

                  3. 6

                    Hi there! I’m Aloke, an engineer at Warp and author of the blog post. Happy to answer any questions.

                    If you are interested, you can join the waitlist for Warp here: https://www.warp.dev/ and our discord community here https://discord.com/invite/T2p5xFgpjr

                    1. 1

                      Hm this part is interesting:

                      To fix these issues, we create a separate grid for each command and output based on the precmd/preexec hooks we receive from the shell. This level of grid isolation ensures we can separate commands and their output without having to deal with the output of one command overwriting that of another. We found this approach to be a good balance of being faithful to the VT100 spec and using the existing Alacritty grid code with rendering blocks in a more flexible way that was traditionally prescribed by a teletype terminal.

                      This is a creative solution and makes sense for compatibility. I’d be interested any corner cases that don’t work, i.e. does it handle async commands with & ? To me it would be nice to pop out another tab for that or something.

                      Oil has started to provide an API over Unix domain sockets to give a “headless shell”.


                      Basically what I want to do is punt the whole UI question elsewhere, since I’m mainly focused on shell as a programming language.

                      So I envision all the shell UI could be in a rich browser-like GUI (optionally, you can obviously still use a terminal).

                      I’d say the GUI should have a terminal, but it doesn’t have to be a terminal. In other words, I think of shell as a language-oriented interface, but not necessarily a terminal-oriented one.

                      I talked with the authors of https://www.withfig.com/ a little bit. They also have a create solution with the OS X accessibility framework to parse shell via OS hooks. I think the preexec hooks have a similar flavor. But really shells should allow more introspection and Oil is on its way. If you’re interested in exploring any of these things feel free to join https://www.oilshell.zulipchat.com/ . There is very nascent work on a client for a headless shell there.

                      1. 1

                        I spent about ten minutes yesterday hunting for the waitlist signup form, then gave up. Looked again right now and still can’t find it. I’m using Safari on an iPad; maybe there’s some layout glitch hiding the form on smaller screens?

                        1. 2

                          huh sorry about that, there’s an issue on some versions of Safari where the request access button doesn’t work, we’re in the process of getting in a fix.

                          In the meantime you can find the form here: https://zachlloyd.typeform.com/to/yrwMkgtj?typeform-embed=oembed&typeform-medium=embed-oembed

                      2. 5

                        Small nit but the homepage taking hostage of scroll drives me mad.

                        1. 5

                          A terminal implements the VT100 spec…

                          twitch I’m fine. Everything is fine.

                          1. 3

                            Could be worse :

                            A terminal implements the xterm spec…

                            1. 2

                              I don’t know anything about this. Why does this bother you?

                              1. 5

                                So these sorts of programs are called terminal emulators because they’re emulating the hardware terminals of old.

                                There were as many terminals as there were vendors as each one had their own control sequences.

                                Various standards bodies (notably ECMA and ANSI) collaborated to create a standard set of control sequences for terminals.

                                The VT100 was one of the first to implement (part of) the standard, and spawned a legacy of backward-compatible terminals. It was so popular that people often emulated (with varying degrees of accuracy) a VT100 rather than try to conform to the standard.

                                The things with the article’s comment that bother me (though not in any real serious way):

                                • The VT100 is not a standard. It was a particular, partial implementation of the ANSI/ECMA standard.
                                • The VT100 did not support a lot of things that we expect from modern terminals: color, sizes other than 80/132 columns, more than four function keys, etc.
                                • The VT100 did support things we don’t see much in modern terminals: double height characters, for example.
                                • There’s much acrimony in the terminal emulation world about saying “I emulate a VT100/xterm/whatever” when in fact you only emulate a subset of that. So many modern terminals say they’re an “xterm-256color” but they don’t emulate 90% of the very many sequences supported by the real xterm, meaning nobody can actually assume they’re running on a real xterm even if the terminal says it is one…Something similar happened in the 70s/80s/90s with terminals claiming to be VT100’s but not actually being so…
                                • The VT100 did some things in a weird way that are not part of the ANSI/ECMA standard and that not all modern terminals support (the xenl glitch is a pain in the butt to get right, especially in light of wide characters).
                                • It is now generally accepted that all modern terminal emulators will support things like ANSI SGR (Set Graphics Rendition) codes to change colors/bold/underline, the basic ANSI cursor motion commands (though not all; many terminals don’t implement the HPR/HPA codes, for example).
                                • There are still a million different terminal emulators, all kinda-sorta compatible. That’s why you still need curses, etc.

                                It’s kinda assumed that things are broadly a superset of the VT100, adding on things like color and what have you from ANSI, but even that’s not really true: with very few exceptions nobody implements the VT100’s double-height characters or VT52 mode.

                                In other words, most (but by no means all) terminals these days implement a subset of the ANSI standard that is roughly a superset of what the VT100 implemented, but it’s definitely not a strict superset, and the supersets are all kinda different.

                                (My terminal multiplexer, mtm implements about as much of the VT100’s behavior as can be done in modern terminals with curses…)

                                1. 2

                                  Thank you for the long and in-depth response!

                            2. 3

                              I signed up to the waiting list yesterday and really want to start testing it. Currently I’m using Alacritty + tmux and I wonder how it compares to it.

                              1. 3

                                Is Apple’s Metal cross-platform? The post implies it is

                                Multiplatform, including supporting the Web: Warp needs to run on multiple platforms, including rendering Warp in a browser to support real-time collaboration.

                                But the rest of the post heavily implies it’s only for Mac OS.

                                1. 6

                                  Right, we started with Metal because we targeted MacOS first. We’re currently in the process of building against WebGL so you can use Warp on the web and then we’ll focus on Linux and Windows via OpenGL.

                                  1. 4

                                    That section of the post is about future plans.

                                    1. 3

                                      OK, so the first release will be Mac only.

                                  2. 2

                                    I wonder how feasible would be to bypass the pseudoterminal choke-point entirely, and just integrate terminal and shell directly?

                                    1. 3

                                      It’s trivial in terms of MVP (just a repl where e is string split + Command::run), moderately annoying in terms of UX feature parity (using fish gives you autosuggestions, customizable prompt, and other things you’d have to implement yourself otherwise), and rather challenging in terms of ecosystem adoption (people use vim, readline, ncurses).

                                      But yeah, terminal/shell split generally makes no sense today, I hope they add some kind of “built in” shell in the future, and generally fulfill my new shell program :-)

                                      1. 1

                                        I would rather have a well defined set of escape sequences that the terminal can interpret for non-traditional formatting. For example, what if there were an escape sequence for an expandable bulleted list? Many programs could take advantage of something like that; why should the shell be special?

                                        1. 1

                                          Yes, there’s no reason to not define an IPC mechanism for that. Though I’d use output mimetypes rather than escape sequences.

                                      2. 1

                                        Isn’t that kinda tmux?

                                        1. 1

                                          It also uses a pty.

                                        2. 1


                                          1. 1

                                            eshell is maybe reasonably close, if you consider emacs as your terminal

                                          2. 2

                                            This sounds great, but I am not sold on the idea that the tty interface is totally obsolete these days because we’re no longer in a world of mechanical teletypes.

                                            We’re not, but we are in a world of network connectivity. The “my user is interacting with me via an external device that sends and receives streams of bytes to me” concept turns out to map really well to things like ssh.

                                            If anything, it’s possible we’re not leaning into the tty model hard enough. In addition to the “bytes in, bytes out” aspect of ttys, there’s a slew of settings for things like parity and baud rate and local echo of input and hotkeys for process suspension. What if, in addition to a fixed set of attributes hardwired into the ioctl API, we could define attributes in user space, and shells could do some moral equivalent of ioctl(0, "CurrentCommand", "/usr/bin/python") instead of a bunch of vt100 escape sequence hacks, and the terminal software could listen for that and update its UI accordingly?

                                            (I bet someone has explored this already and I just haven’t run across it.)

                                            1. 2

                                              Given that Gate One has been Free Software for a while, I’m not sure what the appeal of an unfree service is supposed to be. Also, I once was paid to integrate Gate One, and it’s not pleasant; most of what was difficult was intrinsic to the problem of integrating a terminal into a Web page. I just hope that these folks remember to release their source code when they run out of funding, rather than misusing customer data.

                                              1. 3

                                                The thing you linked seems to be quite different from what this project is actually proposing. At least in the interface aspect.

                                                This (the post’s link) also looks like it wants to be more than just a terminal on the browser (it explicitly says it’s not browser based, actually).