7 ms·

The terminal is on life support. Is it worth saving?

veltas 5y ago
On a normal readline terminal like bash you already are basically using a text editor.
Ashanmaril 5y ago
I don't know if I care about collaboration or the division into blocks, but there is something to be said about how inputting text into a terminal is a completely different mode of operation. I'm alright at getting around in a text editor with system-level keyboard shortcuts, but as soon as I'm typing into a terminal input buffer I feel like I'm in a weird uncanny valley version of typing. Like how I can't do shift + left/right to highlight text and instead it throws in some hexidecimal number that I then have to delete.
- flib 5y ago
  Anyone have a better input control for terminals? I have this same issue and have never been able to better it.
  - yunohn 5y ago
    +1, I can salvage some level of text editing functionality with a black-box incantation of bash settings, but it never feels perfect and half of the shortcuts still fail to work. Basic stuff - like jumping/selecting words, going to the start/end of the line, anything really - needs configuration. Even worse, half of it breaks when I ssh into another machine.
    - eddieh 5y ago
      At the shell prompt type Ctrl-X Ctrl-E to edit in your $EDITOR
      - yunohn 5y ago
        That’s already more effort than not needing to do anything, because the terminal isn’t a weirdo text input relative to my IDE/editor.
        eddieh 5y ago
        I agree. That’s why I mostly use Eshell in Emacs, but if for some reason I’m in a stand-alone terminal emulator and need some advanced editing capabilities ^X ^E saves the day by firing up Emacs on the current input.
zachlloyd 5y ago
Thanks Peter for posting about us. Hi HN, I’m Zach, the author of the post and founder at Warp—a blazingly fast Rust-based terminal. TLDR; The terminal isn’t built for how modern software engineers work. Software development moved to reusability, composability and collaboration years ago. Terminals are still inherently single-user, linear, and ephemeral because the terminal-shell interface was built during a time people were using physical teletype terminals. This makes it hard for teams to effectively collaborate on production issues, track what actions people are taking, and recall prior events. The terminal-shell interface, which hasn’t changed since the 80s, needs to be rethought if we want to bring the terminal into the modern age. At Warp, we’re holistically rethinking how the terminal should work to bring it into the modern age. To start, we’ve built shell integrations into Bash, ZSH, and Fish as an additional interface between the terminal and the shell. This interface allows us to group commands and their outputs together, allowing users to take actions on “blocks” i.e. copy/paste, scrolling, sharing. We currently have integrations for bash, zsh, and fish. We’ve also: * Replaced the prompt with a full-fledged editor * Added Visual menus for history & tab completions * Built a Command Palette to discover and access all shortcuts See a demo here: https://www.youtube.com/watch?v=X0LzWAVlOC0 https://www.youtube.com/watch?v=X0LzWAVlOC0 Speed is our top priority and so we chose to use Rust and GPU rendering. See our engineering post for how we built Warp, including how we co-built our own UI framework for Rust: https://blog.warp.dev/how-warp-works/ https://blog.warp.dev/how-warp-works/ Our terminal model code is based on Alacritty’s model code; we’re grateful that a few of the collaborators reviewed our early design docs. Huge thanks to our collaborators: Atom co-founder Nathan Sobo [1], Nushell co-founder Andres Robalino [2], and Fish shell lead developer Peter Ammon [3]! We hope to open source the client soon. Ask me anything! [1] https://github.com/nathansobo https://github.com/nathansobo [2] https://github.com/andrasio https://github.com/andrasio [3] https://github.com/ridiculousfish https://github.com/ridiculousfish
- onli 5y ago
  Your assumptions as presented in the article are somewhere between wrong and irrelevant. The rest of the article and what you are trying to build is somewhere between interesting and awesome. Maybe the introduction is something to revise, so it doesn't trip bs detectors? > Developers work in teams, but terminals don’t support collaboration Developers do not work in teams for the work they do in terminals. > Developers rely on sharing knowledge, but all my terminal work disappears every time I close a session It does not disappear, for every common configuration I'm aware of. The history persists. > Developers work across machines, but my terminal environment is tethered to my computer You use your terminal to connect to other machines. This is completely irrelevant and misleading for something you actually do on one machine. > Developers are becoming accustomed to nice interfaces, but the terminal inflicts pain and makes me feel like an idiot when I try to do moderately complicated things Are you trying to talk about shells here? The most complicated thing I do with terminals is to type text, which is the point and does nothing of the kind. Maybe there is a little truth in this when talking about copy/paste usually not working with CTRL+C/CTRL+V, but that's trivial. This sounds awfully negative, sorry about that. But it's really the text that provokes that. The remainder of the article is better, included graphical auto-completion could be nice for discoverability (if it's better than what pressing tab already offers because of the descriptions). Chat in the terminal I would never want, but well, then I'm not the target.
smoldesu 5y ago
The terminal is only on life support if you aren't using it. Adding a command palette won't fix it, targeting Mac-first builds? Forget it, your project is already deader than the terminal it replaces.
- marktangotango 5y ago
  > This post introduces Warp, a new Rust-based terminal If one of the main selling points is the language used to implement it, then what do you really have? I propose that the preponderous of "x in y" indicates the death of innovation more than anything.
- vgel 5y ago
  I found the title of the article a little annoying, but it has a point. It's ridiculous that we're using terminals that still emulate a physical TTY, with all the flaws that come with that. The failings of terminal semantics have been well-documented (tools with frozen text UI formats because so many tools rely on parsing their output...), but the failings of the terminal UI are large too. Why does editing a multi-line command have to be a pain? Why do the Vim bindings have to suck? Why do I have to screw around adding random files to my ZSH autocomplete directory, or application developers need to add some completion installer for each type of shell? Why can't I tell the shell to color-code stderr vs stdout? Why can't a program open more than 2 IO channels to the terminal? Why is there still not a standard way to display images and video? Why can't the terminal fold long command output into a toggleable expando (like code-folding) instead of me needing to up-arrow to remember what I ran? Why can't I filter output after the fact instead of needing to remember to grep it or tee it into a file and grep that? Shells have fallen way, way behind what modern GUI editors (and TUI ones, more hackily) are able to do. It's easy to write off these kinds of improvements, but 30s re-running a command to grep output there and a minute checking man pages there interrupt your flow and add up to really be a huge waste of time. There's no reason we should be emulating physical terminals in 2021.
  - smoldesu 5y ago
    A project like this will only solve maybe ~25% of the gripes you just mentioned, and it certainly won't improve the current interop between terminals. I share your frustration with how archaic it can seem sometimes, but terminals will persist until we stop using hardware that accommodates them. I'd rather see a terminal that embraces these esoteric design flaws, finally providing a reliable cross-platform terminal. Rust would have been the perfect language for that, but it seems like the current devs don't really consider compatibility a priority.
josegonzalez 5y ago
Did a startup writing a terminal replacement write this?
- api 5y ago
  Terminals have no subscription model, closed-source backend, or telemetry. Gotta fix that.
- EamonnMR 5y ago
  Yes, check the homepage. The blog post is excellent bait though, bravo.
dec0dedab0de 5y ago
I agree that terminals have plenty of room for improvement, but this whole article feels like marketing fluff. My brain turned off in the middle of it. I think you should have waited until you had a demo then did a show hn
gipp 5y ago
This looks like a potentially cool project, but some of the marketing here is pretty off-putting. First of all the idea that the terminal is "on life support" is laughable, what tool is more universal? And > Why doesn’t the terminal work like the rest of your apps? Developer tools have evolved towards reusability, composability, and collaboration. Terminal workflows may be the single best tool in the first 2 of those 3 categories.
- jaren 5y ago
  i view the marketing as showing they care about product and users here
  - gipp 5y ago
    Yeah, I mean maybe I'm overreacting -- I'm all for a better terminal, and there's some genuinely cool stuff here -- it's just undermining its own case by overselling IMO.
    - MisterTea 5y ago
      > Yeah, I mean maybe I'm overreacting No, you're reaction is perfectly reasonable for such nonsensical hyperbole.
  - salawat 5y ago
    I don't. If they did, they'd recognize the fact that the entire concept of "Apps", collaboration, etc..., are examples of ways human beings assemble tools to interact. Terminals are one of the most direct ways to interact with hardware. If you need to share your hardware with someone else, then you share your screen or a recording. If you need to share your environment or she'll settings, you share scripts. There's nothing to terminal use to be gained by trying to shoehorn in more net connections, and more uncertainty by merging in more sources of input. By cramming that in you are doing the opposite of caring about users. You're introducing extra elements that can break, decreasing the overall learnability of the system.
vsviridov 5y ago
Have been doing development predominately in the terminal for the last 15 years... Have no idea what this guy is taking about... IMO this is trying to fix something that isn't broken.
EamonnMR 5y ago
On the contrary, the terminal is experiencing something of a renewal with people suddenly caring enough to try ZSH to the point where MacOS is now pushing it, Fish getting traction, and there was a new BASH release in '19.
- stickfigure 5y ago
  MacOS switched to zsh because of licensing issues, no? That doesn't quite sound like "caring".
  - EamonnMR 5y ago
    I would have assumed they'd just grab a bsd shell, but maybe bsd distros use zsh now, I'm way out of the loop there.
- hashhar 5y ago
  Bash has had on an average 1 to 2 releases every year for the last few years.
PragmaticPulp 5y ago
In case it wasn’t clear, this is a marketing piece by a startup producing this as a product. As far as I can tell, the main features are: 1. Terminal commands and outputs are divided into blocks 2. Input is handled as a text editor 3. Multiuser collaboration tools Despite the over-the-top marketing hyperbole, I'm curious. I’d really have to see this in practice to know how practical some of these features are. The great thing about traditional terminals is that the bugs and quirks were generally ironed out years ago. I’m hesitant to introduce anything into my workflow where I might spend a lot of timing fighting the tool or chasing tweaks to get things to work right.
- cyberge99 5y ago
  Appropriate username.
- sime2009 5y ago
  If you want to play with the idea of having command output divided into blocks, you can go try it in my terminal Extraterm (https://extraterm.org/ https://extraterm.org/) which has had it for years. Or just have a look at the gifs on the features page to get an idea of what is possible: https://extraterm.org/features.html https://extraterm.org/features.html (halfway down page)
  - xrayarx 5y ago
    Wow, the best terminal no one ever heard of! I am going to try this right now!
  - mech422 5y ago
    Thats pretty nifty !
  - stonecharioteer 5y ago
    Holy crap. How is this not more popular?!
mftb 5y ago
The title and opening paragraphs of this article are so aggravating and misguided I almost didn't make it to the end to find out about the interesting technology they have to talk about. Now I can't remember it's name because of the stuff about "the terminal being on life support". Poor approach, hopefully it'll come up again later.
yakshaving_jgt 5y ago
I like my terminal as it is and I don't feel the pain outlined in the problem statement. The pain I feel is performance — I need my prompt to be instant; for a while I had to wait ~300ms for each render, which in terminal land is basically a year. For collaboration there's tmux/tmate. The completion examples already exist in my relatively meagre oh-my-zsh setup. The other completion stuff is done with fzf. I generally don't like GUI stuff, and as for "developers work across machines", well, this old Steve Losh gem[0] comes to mind: > I can count on my balls how many times I've sat down to program at someone else's computer in the last five years. It just never happens. That said, I think Warp looks great, and there's definitely space in the world for more terminal options. This could be an excellent gateway drug to entice more developers over to using the CLI, which is an obvious positive. Way too many programmers are hampering themselves by not working with the terminal. [0]: https://www.reddit.com/r/vim/comments/2c3cuu/a_quick_tour_of_steve_loshs_massive_vimrc/cjc4jnj/?utm_source=share&utm_medium=ios_app&utm_name=iossmf https://www.reddit.com/r/vim/comments/2c3cuu/a_quick_tour_of...
- thedracle 5y ago
  I agree, I am definitely happy with my terminal experience in general, and there is an equivalent for most of the features using a combination of TMux/ZShell/vi mode, etc etc... It actually feels like I'm living less of my life in UIs these days, and more in the terminal than I did in the 90s/early 2ks. I've definitely felt some performance improvement using Alacritty: https://github.com/alacritty/alacritty https://github.com/alacritty/alacritty
  - yunohn 5y ago
    I think most people aren’t comfortable building a strung together shell environment, full of third-party tools to enable things like completion, search, sessions, etc. HN might have a lot of people who do, but I’d anecdotally wager that even that isn’t much. Having a terminal that has everything out of the box, without breaking due to incompatibility between the various tools, is a MASSIVE improvement.
    - 5y ago
robterrell 5y ago
For me, the ideal terminal is a modern GUI document, backed by a file, with cut-copy-paste, mouse editing, and an insertion point. Using the "terminal" shouldn't be a weird different mode of interaction. BBEdit's Worksheet is the closest I've seen to this (and before that, MPW, but now I'm just showing my age). But BBEdit doesn't handle curses, which can be very limiting.
gexla 5y ago
Anything beyond straight CLI commands which I can get from a man page is "power user" territory. You're working with a limited market by going after these people. As I get older, I want less, not more. If I do decide for more, then it's going to be furthering my usage on what has already been available for decades, not the newest shiny thing. Further, I'm going to trust old tools which are still regularly updated over something I would place a significant chance on not being around in 5 years. Developers make good or bad software regardless of the approach they have taken for the interface. There are CLI's which spark joy and GUI's which I won't waste time on. Will building a better terminal make a CLI better? I suppose it could, but terminal choice has usually been an after-thought for me (usually go straight to Tmux, which fancy terminal programs often screw up.) Similar to the last point, building the sort of tools which are going to be central to my work is hard. I'm going to use whatever that happens to be regardless of what I feel is my ideal working environment.
greggyb 5y ago
This actually looks pretty cool, but I can't help myself from some quick responses to their first bullets: > Developers work in teams, but terminals don’t support collaboration With SSH, tmux supports full terminal session sharing. > Developers rely on sharing knowledge, but all my terminal work disappears every time I close a session All shells I know of have configurable history settings. rlwrap will give you the ability to have history (and nice input) for anything shell-ish or interpeter-ish in the terminal. > Developers work across machines, but my terminal environment is tethered to my computer All configuration I care about within a terminal can move from machine to machine with typically a single rc file. Often, I don't even need to do this, thanks to remote file editing and being able to send commands via SSH without an interactive session. > Developers are becoming accustomed to nice interfaces, but the terminal inflicts pain and makes me feel like an idiot when I try to do moderately complicated things This one is purely subjective and I simply disagree. It's difficult to engage. A day with your shell's manual and you should be good. Any other applications will have learning curves, and I don't find CLI to be significantly better or worse than a GUI for discoverability.
- methyl 5y ago
  These all feels to me like famous Dropbox comment: https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224 Of course you can do some of the stuff Warp does, but you need to have an extensive knowledge. Making them more accessible is always a win.
  - greggyb 5y ago
    I think the cool parts of Warp are outside of those bullets. I wouldn't suggest that the responses to the bullets are a replacement to what the product is doing. I just don't think those bullets make a strong argument on their own. It was a quippy response to a weak intro and not a critique of the product.
mr_vile 5y ago
In the world of real advancements in terminal development, Plan 9 had come up with Blit and drawterm in the 90's -- so why haven't we made it back to there yet? the answer mostly lies in the lack of simple drawing primitives in X, the TTY interfaces, etc. People like this warp.dev guy come along every few months and poo-poo everything because secretly they do not want to learn it (and neither do we, really!). But nobody really comes along and tries to fix the termcap-brained mindset we still have when considering terminal design. It seems like after everyone got 256-colour and 24-bit colour support we have just accepted the state of things.
adamtaoca 5y ago
It is really cool project. Thanks

On a normal readline terminal like bash you already are basically using a text editor.

I don't know if I care about collaboration or the division into blocks, but there is something to be said about how inputting text into a terminal is a completely different mode of operation. I'm alright at getting around in a text editor with system-level keyboard shortcuts, but as soon as I'm typing into a terminal input buffer I feel like I'm in a weird uncanny valley version of typing. Like how I can't do shift + left/right to highlight text and instead it throws in some hexidecimal number that I then have to delete.

flib 5y ago
Anyone have a better input control for terminals? I have this same issue and have never been able to better it.
- yunohn 5y ago
  +1, I can salvage some level of text editing functionality with a black-box incantation of bash settings, but it never feels perfect and half of the shortcuts still fail to work. Basic stuff - like jumping/selecting words, going to the start/end of the line, anything really - needs configuration. Even worse, half of it breaks when I ssh into another machine.
  - eddieh 5y ago
    At the shell prompt type Ctrl-X Ctrl-E to edit in your $EDITOR
    - yunohn 5y ago
      That’s already more effort than not needing to do anything, because the terminal isn’t a weirdo text input relative to my IDE/editor.
      - eddieh 5y ago
        I agree. That’s why I mostly use Eshell in Emacs, but if for some reason I’m in a stand-alone terminal emulator and need some advanced editing capabilities ^X ^E saves the day by firing up Emacs on the current input.

zachlloyd 5y ago

Thanks Peter for posting about us. Hi HN, I’m Zach, the author of the post and founder at Warp—a blazingly fast Rust-based terminal. TLDR; The terminal isn’t built for how modern software engineers work. Software development moved to reusability, composability and collaboration years ago. Terminals are still inherently single-user, linear, and ephemeral because the terminal-shell interface was built during a time people were using physical teletype terminals. This makes it hard for teams to effectively collaborate on production issues, track what actions people are taking, and recall prior events. The terminal-shell interface, which hasn’t changed since the 80s, needs to be rethought if we want to bring the terminal into the modern age. At Warp, we’re holistically rethinking how the terminal should work to bring it into the modern age. To start, we’ve built shell integrations into Bash, ZSH, and Fish as an additional interface between the terminal and the shell. This interface allows us to group commands and their outputs together, allowing users to take actions on “blocks” i.e. copy/paste, scrolling, sharing. We currently have integrations for bash, zsh, and fish. We’ve also: * Replaced the prompt with a full-fledged editor * Added Visual menus for history & tab completions * Built a Command Palette to discover and access all shortcuts See a demo here: https://www.youtube.com/watch?v=X0LzWAVlOC0 https://www.youtube.com/watch?v=X0LzWAVlOC0 Speed is our top priority and so we chose to use Rust and GPU rendering. See our engineering post for how we built Warp, including how we co-built our own UI framework for Rust: https://blog.warp.dev/how-warp-works/ https://blog.warp.dev/how-warp-works/ Our terminal model code is based on Alacritty’s model code; we’re grateful that a few of the collaborators reviewed our early design docs. Huge thanks to our collaborators: Atom co-founder Nathan Sobo [1], Nushell co-founder Andres Robalino [2], and Fish shell lead developer Peter Ammon [3]! We hope to open source the client soon. Ask me anything! [1] https://github.com/nathansobo https://github.com/nathansobo [2] https://github.com/andrasio https://github.com/andrasio [3] https://github.com/ridiculousfish https://github.com/ridiculousfish

onli 5y ago
Your assumptions as presented in the article are somewhere between wrong and irrelevant. The rest of the article and what you are trying to build is somewhere between interesting and awesome. Maybe the introduction is something to revise, so it doesn't trip bs detectors? > Developers work in teams, but terminals don’t support collaboration Developers do not work in teams for the work they do in terminals. > Developers rely on sharing knowledge, but all my terminal work disappears every time I close a session It does not disappear, for every common configuration I'm aware of. The history persists. > Developers work across machines, but my terminal environment is tethered to my computer You use your terminal to connect to other machines. This is completely irrelevant and misleading for something you actually do on one machine. > Developers are becoming accustomed to nice interfaces, but the terminal inflicts pain and makes me feel like an idiot when I try to do moderately complicated things Are you trying to talk about shells here? The most complicated thing I do with terminals is to type text, which is the point and does nothing of the kind. Maybe there is a little truth in this when talking about copy/paste usually not working with CTRL+C/CTRL+V, but that's trivial. This sounds awfully negative, sorry about that. But it's really the text that provokes that. The remainder of the article is better, included graphical auto-completion could be nice for discoverability (if it's better than what pressing tab already offers because of the descriptions). Chat in the terminal I would never want, but well, then I'm not the target.

smoldesu 5y ago

The terminal is only on life support if you aren't using it. Adding a command palette won't fix it, targeting Mac-first builds? Forget it, your project is already deader than the terminal it replaces.

marktangotango 5y ago
> This post introduces Warp, a new Rust-based terminal If one of the main selling points is the language used to implement it, then what do you really have? I propose that the preponderous of "x in y" indicates the death of innovation more than anything.
vgel 5y ago
I found the title of the article a little annoying, but it has a point. It's ridiculous that we're using terminals that still emulate a physical TTY, with all the flaws that come with that. The failings of terminal semantics have been well-documented (tools with frozen text UI formats because so many tools rely on parsing their output...), but the failings of the terminal UI are large too. Why does editing a multi-line command have to be a pain? Why do the Vim bindings have to suck? Why do I have to screw around adding random files to my ZSH autocomplete directory, or application developers need to add some completion installer for each type of shell? Why can't I tell the shell to color-code stderr vs stdout? Why can't a program open more than 2 IO channels to the terminal? Why is there still not a standard way to display images and video? Why can't the terminal fold long command output into a toggleable expando (like code-folding) instead of me needing to up-arrow to remember what I ran? Why can't I filter output after the fact instead of needing to remember to grep it or tee it into a file and grep that? Shells have fallen way, way behind what modern GUI editors (and TUI ones, more hackily) are able to do. It's easy to write off these kinds of improvements, but 30s re-running a command to grep output there and a minute checking man pages there interrupt your flow and add up to really be a huge waste of time. There's no reason we should be emulating physical terminals in 2021.
- smoldesu 5y ago
  A project like this will only solve maybe ~25% of the gripes you just mentioned, and it certainly won't improve the current interop between terminals. I share your frustration with how archaic it can seem sometimes, but terminals will persist until we stop using hardware that accommodates them. I'd rather see a terminal that embraces these esoteric design flaws, finally providing a reliable cross-platform terminal. Rust would have been the perfect language for that, but it seems like the current devs don't really consider compatibility a priority.

josegonzalez 5y ago

Did a startup writing a terminal replacement write this?

api 5y ago
Terminals have no subscription model, closed-source backend, or telemetry. Gotta fix that.
EamonnMR 5y ago
Yes, check the homepage. The blog post is excellent bait though, bravo.

dec0dedab0de 5y ago

I agree that terminals have plenty of room for improvement, but this whole article feels like marketing fluff. My brain turned off in the middle of it. I think you should have waited until you had a demo then did a show hn

gipp 5y ago

This looks like a potentially cool project, but some of the marketing here is pretty off-putting. First of all the idea that the terminal is "on life support" is laughable, what tool is more universal? And > Why doesn’t the terminal work like the rest of your apps? Developer tools have evolved towards reusability, composability, and collaboration. Terminal workflows may be the single best tool in the first 2 of those 3 categories.

jaren 5y ago
i view the marketing as showing they care about product and users here
- gipp 5y ago
  Yeah, I mean maybe I'm overreacting -- I'm all for a better terminal, and there's some genuinely cool stuff here -- it's just undermining its own case by overselling IMO.
  - MisterTea 5y ago
    > Yeah, I mean maybe I'm overreacting No, you're reaction is perfectly reasonable for such nonsensical hyperbole.
- salawat 5y ago
  I don't. If they did, they'd recognize the fact that the entire concept of "Apps", collaboration, etc..., are examples of ways human beings assemble tools to interact. Terminals are one of the most direct ways to interact with hardware. If you need to share your hardware with someone else, then you share your screen or a recording. If you need to share your environment or she'll settings, you share scripts. There's nothing to terminal use to be gained by trying to shoehorn in more net connections, and more uncertainty by merging in more sources of input. By cramming that in you are doing the opposite of caring about users. You're introducing extra elements that can break, decreasing the overall learnability of the system.

vsviridov 5y ago

Have been doing development predominately in the terminal for the last 15 years... Have no idea what this guy is taking about... IMO this is trying to fix something that isn't broken.

EamonnMR 5y ago

On the contrary, the terminal is experiencing something of a renewal with people suddenly caring enough to try ZSH to the point where MacOS is now pushing it, Fish getting traction, and there was a new BASH release in '19.

stickfigure 5y ago
MacOS switched to zsh because of licensing issues, no? That doesn't quite sound like "caring".
- EamonnMR 5y ago
  I would have assumed they'd just grab a bsd shell, but maybe bsd distros use zsh now, I'm way out of the loop there.
hashhar 5y ago
Bash has had on an average 1 to 2 releases every year for the last few years.

PragmaticPulp 5y ago

In case it wasn’t clear, this is a marketing piece by a startup producing this as a product. As far as I can tell, the main features are: 1. Terminal commands and outputs are divided into blocks 2. Input is handled as a text editor 3. Multiuser collaboration tools Despite the over-the-top marketing hyperbole, I'm curious. I’d really have to see this in practice to know how practical some of these features are. The great thing about traditional terminals is that the bugs and quirks were generally ironed out years ago. I’m hesitant to introduce anything into my workflow where I might spend a lot of timing fighting the tool or chasing tweaks to get things to work right.

cyberge99 5y ago
Appropriate username.
sime2009 5y ago
If you want to play with the idea of having command output divided into blocks, you can go try it in my terminal Extraterm (https://extraterm.org/ https://extraterm.org/) which has had it for years. Or just have a look at the gifs on the features page to get an idea of what is possible: https://extraterm.org/features.html https://extraterm.org/features.html (halfway down page)
- xrayarx 5y ago
  Wow, the best terminal no one ever heard of! I am going to try this right now!
- mech422 5y ago
  Thats pretty nifty !
- stonecharioteer 5y ago
  Holy crap. How is this not more popular?!

mftb 5y ago

The title and opening paragraphs of this article are so aggravating and misguided I almost didn't make it to the end to find out about the interesting technology they have to talk about. Now I can't remember it's name because of the stuff about "the terminal being on life support". Poor approach, hopefully it'll come up again later.

yakshaving_jgt 5y ago

I like my terminal as it is and I don't feel the pain outlined in the problem statement. The pain I feel is performance — I need my prompt to be instant; for a while I had to wait ~300ms for each render, which in terminal land is basically a year. For collaboration there's tmux/tmate. The completion examples already exist in my relatively meagre oh-my-zsh setup. The other completion stuff is done with fzf. I generally don't like GUI stuff, and as for "developers work across machines", well, this old Steve Losh gem[0] comes to mind: > I can count on my balls how many times I've sat down to program at someone else's computer in the last five years. It just never happens. That said, I think Warp looks great, and there's definitely space in the world for more terminal options. This could be an excellent gateway drug to entice more developers over to using the CLI, which is an obvious positive. Way too many programmers are hampering themselves by not working with the terminal. [0]: https://www.reddit.com/r/vim/comments/2c3cuu/a_quick_tour_of_steve_loshs_massive_vimrc/cjc4jnj/?utm_source=share&utm_medium=ios_app&utm_name=iossmf https://www.reddit.com/r/vim/comments/2c3cuu/a_quick_tour_of...

thedracle 5y ago
I agree, I am definitely happy with my terminal experience in general, and there is an equivalent for most of the features using a combination of TMux/ZShell/vi mode, etc etc... It actually feels like I'm living less of my life in UIs these days, and more in the terminal than I did in the 90s/early 2ks. I've definitely felt some performance improvement using Alacritty: https://github.com/alacritty/alacritty https://github.com/alacritty/alacritty
- yunohn 5y ago
  I think most people aren’t comfortable building a strung together shell environment, full of third-party tools to enable things like completion, search, sessions, etc. HN might have a lot of people who do, but I’d anecdotally wager that even that isn’t much. Having a terminal that has everything out of the box, without breaking due to incompatibility between the various tools, is a MASSIVE improvement.
  - 5y ago

robterrell 5y ago

For me, the ideal terminal is a modern GUI document, backed by a file, with cut-copy-paste, mouse editing, and an insertion point. Using the "terminal" shouldn't be a weird different mode of interaction. BBEdit's Worksheet is the closest I've seen to this (and before that, MPW, but now I'm just showing my age). But BBEdit doesn't handle curses, which can be very limiting.

gexla 5y ago

Anything beyond straight CLI commands which I can get from a man page is "power user" territory. You're working with a limited market by going after these people. As I get older, I want less, not more. If I do decide for more, then it's going to be furthering my usage on what has already been available for decades, not the newest shiny thing. Further, I'm going to trust old tools which are still regularly updated over something I would place a significant chance on not being around in 5 years. Developers make good or bad software regardless of the approach they have taken for the interface. There are CLI's which spark joy and GUI's which I won't waste time on. Will building a better terminal make a CLI better? I suppose it could, but terminal choice has usually been an after-thought for me (usually go straight to Tmux, which fancy terminal programs often screw up.) Similar to the last point, building the sort of tools which are going to be central to my work is hard. I'm going to use whatever that happens to be regardless of what I feel is my ideal working environment.

greggyb 5y ago

This actually looks pretty cool, but I can't help myself from some quick responses to their first bullets: > Developers work in teams, but terminals don’t support collaboration With SSH, tmux supports full terminal session sharing. > Developers rely on sharing knowledge, but all my terminal work disappears every time I close a session All shells I know of have configurable history settings. rlwrap will give you the ability to have history (and nice input) for anything shell-ish or interpeter-ish in the terminal. > Developers work across machines, but my terminal environment is tethered to my computer All configuration I care about within a terminal can move from machine to machine with typically a single rc file. Often, I don't even need to do this, thanks to remote file editing and being able to send commands via SSH without an interactive session. > Developers are becoming accustomed to nice interfaces, but the terminal inflicts pain and makes me feel like an idiot when I try to do moderately complicated things This one is purely subjective and I simply disagree. It's difficult to engage. A day with your shell's manual and you should be good. Any other applications will have learning curves, and I don't find CLI to be significantly better or worse than a GUI for discoverability.

methyl 5y ago
These all feels to me like famous Dropbox comment: https://news.ycombinator.com/item?id=9224 https://news.ycombinator.com/item?id=9224 Of course you can do some of the stuff Warp does, but you need to have an extensive knowledge. Making them more accessible is always a win.
- greggyb 5y ago
  I think the cool parts of Warp are outside of those bullets. I wouldn't suggest that the responses to the bullets are a replacement to what the product is doing. I just don't think those bullets make a strong argument on their own. It was a quippy response to a weak intro and not a critique of the product.

mr_vile 5y ago

In the world of real advancements in terminal development, Plan 9 had come up with Blit and drawterm in the 90's -- so why haven't we made it back to there yet? the answer mostly lies in the lack of simple drawing primitives in X, the TTY interfaces, etc. People like this warp.dev guy come along every few months and poo-poo everything because secretly they do not want to learn it (and neither do we, really!). But nobody really comes along and tries to fix the termcap-brained mindset we still have when considering terminal design. It seems like after everyone got 256-colour and 24-bit colour support we have just accepted the state of things.

adamtaoca 5y ago

It is really cool project. Thanks