16 ms·

Why is the terminal input so weird?

110 points by zachlloyd 4y ago

blitz_skull 4y ago
Wow. The intent and the idea is so cool. But it's so clearly been touched by VC funding, it almost makes me wonder if this is a (really expensive) gag. Requires an account? Check. Crashes IMMEDIATELY upon opening? Check. Doesn't support any tool I use (e.g. FZF, key-bindings, etc)? Check. Spammy "iS tHe tErMiNaL oN lIfE sUpPoRt?" blog post? Check. Do they even know their target market is mildly allergic to all of the above? Yikes.
raydev 4y ago
I wonder how many people upset about Warp here also use VS Code and don't bother turning telemetry off.
- smoldesu 4y ago
  If you're using Warp it's likely you're not taking your privacy seriously anyways. It only supports MacOS, which has telemetry like OCSP that is impossible to disable.
apetresc 4y ago
I can edit the terminal input line with full vim-mode in my shell (zsh). In fact, in normal mode I can even hit 'v' and edit the line in a full vim session to zip around however I want, do completions, etc. It's pretty close to the platonic ideal method of input I could imagine.
- ploum 4y ago
  I’m also using vim mode in zsh with simply "bindkey -v". I’m interested by your "v" as full vim session shortcut. Do you mind sharing the config?
  - apetresc 4y ago
    It's this section of my .zshrc here: # edit long commands autoload -U edit-command-line bindkey -M vicmd v edit-command-line That `edit-command-line` autoload script is part of zshcontrib and should be installed by default on any recent zsh distribution. I've never encountered a server I've ssh'ed into that didn't have it. Enjoy :)
    - ploum 4y ago
      Thanks. Also learned about "fc" to edit the last command entered.
    - ploum 4y ago
      If someone from the future read this, I needed to add one more line to make it work: autoload -U edit-command-line zle -N edit-command-line bindkey -M vicmd v edit-command-line
- puffoflogic 4y ago
  The biggest problem with zsh's vim mode is it's actually vi mode. I constantly want "])" and "aw" motions but they're not implemented :( But, like, this is obviously an entirely different class of problem from TFA, which is a skill issue.
- terminal_d 4y ago
  This is also available in bash. In emacs input mode (aka the default) one can press C-x C-e to edit the current command in an editor. `v` is also available in vi input mode.
smoldesu 4y ago
As much as I'd like to encourage the rethinking of input methods, any terminal with a "Pricing" page is an instant nope from me. My current terminal is Open Source and while it's not perfect, it's also Free. That matters more to me than mouse input or IDE autosuggestions. If you're going to treat Linux users as a second-class citizen and charge for corporate usage, who are you hoping your target audience will be? Frankly, I don't ever see this replacing iTerm 2 for most Mac developers. I wish you luck, but your product in it's current state is confusing to me. fish solves most of these issues for me and it runs on all my devices, free. All I'll say is that your competition is stiff.
- danny_warp 4y ago
  The app is 100% free for any and all individuals. The business plan is to create collaborative and cloud-based features that businesses will be willing to pay for. Please check out our pricing page to learn more. Please note that our business model is not about collecting and monetizing any of your personal data. https://www.warp.dev/privacy https://www.warp.dev/privacy
  - KronisLV 4y ago
    > The business plan is to create collaborative and cloud-based features that businesses will be willing to pay for. You know what, that is fair. I know a lot of folks take an issue with software that is monetized and many are jumpy about software that might rugpull them and lock certain features behind a paywall some time down the line, or look into more aggressive forms of monetization, but at the same time a lot of software would probably be better made if it had stable financial backing. I'll probably keep using the most boring terminal setup that's possible just for the sake of not being an early adopter (which is just an excuse because I don't have a Mac), but I'm curious to see how this will play out in the long term, so good luck with your endeavor! > Please check out our pricing page to learn more. Here's the direct link: https://www.warp.dev/pricing https://www.warp.dev/pricing And to save folks a click: Individual A modern terminal experience for individuals. Download now! Free Includes - Block Creation - A.I. Command Search - Workflows - Modern input text editing Team Advanced collaboration and support for teams. Coming soon. Pricing TBD Everything in Individual, Plus - Shared team configurations - Shared team workflows - Real-time terminal sharing - Shared terminal notebooks Enterprise Security, compliance, and flexible deployment. Coming soon. Pricing TBD Everything in Team, plus - Advanced security and compliance - Advanced team deployment - Integration with internal tools
zokier 4y ago
Although I don't like terminals, I think the article overstates the problems to significant degree. The fact that text editors running in terminal still manage to have "ide-like" experience (including mouse input!) proves that you can do a lot with terminals. I still think that trying to move beyond terminals is good idea, but it's important to distinguish what is impossible, and what is just ugly/hacky to do.
- alokedesai 4y ago
  Aloke from the Warp team here--you're totally right that some of these features (syntax highlighting) can be accomplished within the terminal using an editor. In a traditional terminal--you'd have to spend time configuring your shell to get this to work instead of getting these features by default. Some of these features are near-impossible given the current terminal-shell abstraction, however. For example, a traditional terminal has no concept of command input/output, which means that it can't suggest a next command to run based on the output of the previous command.
  - vimda 4y ago
    > it can't suggest a next command to run based on the output of the previous command thefuck (https://github.com/nvbn/thefuck#how-it-works https://github.com/nvbn/thefuck#how-it-works) does exactly that...
    - alokedesai 4y ago
      We collaborated with thefuck to build our version of this :) TF is slightly different in that they actually _rerun_ your last command to get the output since they don't have access to command output
  - zokier 4y ago
    > For example, a traditional terminal has no concept of command input/output, which means that it can't suggest a next command to run based on the output of the previous command. Neither does wayland or whatever. Point being that you can treat terminals as dumb character cell grid display with slightly wonky input mechanism and get quite far ignoring/working around all the traditional line-oriented stuff.
ploum 4y ago
People who do not understand things are poised to reinvent them badly. The post manage to analyse terminal input without having acknowledging readline. So yeah, they have no idea what they are talking about. https://www.masteringemacs.org/article/keyboard-shortcuts-every-command-line-hacker-should-know-about-gnu-readline https://www.masteringemacs.org/article/keyboard-shortcuts-ev...
- sureglymop 4y ago
  They fail to understand that this isn't a problem of the terminal at all... The terminals only job is to display output and to pass through input. They could write an "interactive shell" with mouse support that implements all those features and it would run in any pre existing terminal. They could even make this work with existing shells and it would work over ssh ect. Nothing against innovation but this is the wrong approach imo.
- brenns10 4y ago
  I also disagree with this article's approach, but it seems pretty disingenuous to say that they don't understand terminal input because they didn't mention readline. After all, this is a blog post on the site for a terminal implementation. They'd have to be unbelievably ignorant to not be aware of the role of readline here. They're not writing a technical deep dive, they're presenting their vision for a different approach. I think that vision is flawed but I'm not going to grade them on how deep they get into implementation details.
mostlysimilar 4y ago
I bit and was curious to try Warp. Downloaded it and it immediately made a request to a Google domain and then forced a sign-up window on me. I clicked their "why do we require an account" FAQ and the answer is "we think there are features that are better with a login." Absolute no from me, even if their terminal truly is better and innovative.
drcongo 4y ago
I have one question about terminal input that I cannot work out how to work out. The setup: I'm on a Mac, I use iTerm for my terminal, Fish for my shell, and most often I'm inside a docker container also running Fish and using iPython. The question: When I Ctrl+W to delete a word in a Fish prompt, what counts as a word is different to what counts as a word in iPython. For instance, Ctrl+w at the end of this string `test.func('param1', 'param2')` produces... Fish: test.func('param1', 'param2' iPython: test.func('param1', Hit Ctrl+w again, and you get... Fish: test.func('param1', ' iPython: all gone. This causes me to over delete in iPython many, many times per day. I'm guessing that the rough flow of the delete word signal is iTerm -> Fish -> iPython and that iPython is the thing that's being overzealous?
- theblazehen 4y ago
  > I'm guessing that the rough flow of the delete word signal is iTerm -> Fish -> iPython and that iPython is the thing that's being overzealous? Almost correct. Once you launch iPython, Fish is out of the picture until you quit iPython. However yes iPython does handle Ctrl-W differently from your shell
  - drcongo 4y ago
    Thanks, that helps narrow it down. Next to work out how to make it behave more like fish, as Ctrl+w deleting the entire string `test.func('param1',` seems like madness to me.
- fratajcz 4y ago
  That bothered me too, the default function for Ctrl-W in ipython is unix-word-rubout from python-prompt-toolkit [1], which uses spaces for word boundaries. You can rebind it to backward-kill-word so it uses "not a letter nor a digit" as a word boundary. Here's a gist with my config (also binds shift-left/right arrow to move to previous space instead of visual select): https://gist.github.com/fratajczak/64e32421a43d3b8194d0409ce300518a https://gist.github.com/fratajczak/64e32421a43d3b8194d0409ce... [1]: https://github.com/prompt-toolkit/python-prompt-toolkit/blob/65c3d0607c69c19d80abb052a18569a2546280e5/src/prompt_toolkit/key_binding/bindings/named_commands.py#L386 https://github.com/prompt-toolkit/python-prompt-toolkit/blob...
puffoflogic 4y ago
TL;dr. In zsh (vi mode) I simply press shift-v and I am dropped into my $EDITOR with my current input loaded into a buffer. Of course I rarely need to do this because zsh vi mode covers 99% of my requirements. So, my tldr for an article I didn't finish reading: someone doesn't know how to use their tools and instead of learning they jumped on the internet to complain, and/or sell me a solution or something, idk.
- nsdarren 4y ago
  What's the point of this comment other than being snarky/attempting to show off? You should reflect on it, because this would be a better place if people like you just didn't bother replying. Maybe you don't find it valuable because your setup and mad vi skills offer you an alternative (which I'm very sure is just as feature-rich as what is described in the post, which you didn't read). Isn't it obvious how a more accessible solution might be useful to some people? I for one welcome the efforts of the Warp team to improve terminal UX.
- Stranger43 4y ago
  Interestingly for me this dont work with .zsh out of the box on my mac(i run a deliberately minimalist .zsh) what did you actually do to enable it. esc -> v does work both with bash and mksh on ubuntu with stock config but not out of the box with zsh on my macbook so i suspect there is something missing im my one line .zshrc file. Capital V is an actual vim command btw triggering linewise visual mode and that does somewhat seem to actually seem to be the functionality of shift-v by default in zsh.
  - quesera 4y ago
    > what did you actually do Enable vi mode (usually in .zshrc but you can test from the command line): set -o vi Invoke $EDITOR on the current command line: ls -la /tmp<Esc><v> That's Escape, then the lowercase v key (sequentially, not together) You can use up-arrow to go through command history, reach the one you want to rerun with modifications, then press Esc, v.
    - 4y ago
vander_elst 4y ago
TO better understand the architecture, how will this work if I want to use the shell in vi mode? IIUC that would not be possible with their setup, right? Warp would need to implement a vi mode, correct? Is it possible to work with vim in warp?
- alokedesai 4y ago
  You can launch vim within Warp without any problems, but vi/vim mode for the line editor itself isn't supported in Warp just yet. You're correct that this is because we'd need to implement VI mode ourselves (tracking issue here [1] if you are interested). This is the tradeoff of building our own editor instead of using the shell's--we can build features that wouldn't be possible in the shell directly but it requires us to build features that already exist in the shell from scratch. So far, this tradeoff has been well-worth it to build what we think is a better experience when using the terminal. [1] https://github.com/warpdotdev/Warp/issues/159 https://github.com/warpdotdev/Warp/issues/159
  - vander_elst 4y ago
    Thanks for the answer! Still curious, how does vim work in Warp? Do you know what process are currently running and then you stop buffering the chars and you pass them directly to the process in foreground? I didn't read the code, but from the article it seemed that you pass the text to the shell only when pressing enter, I think in vi(m) you want to do it the whole time (?). If I want to insert something I just type `isomething to insert<Esc>`. How does this work in Warp? What happens if I put the process in background and then in foreground again?
danny_warp 4y ago
Warp currently requires a login to enable cloud-based features, like A.I. Command Search and Block Sharing, along with team features on the roadmap. In case there was any confusion, Warp never sends the contents of terminal commands and outputs to our servers (unless a user explicitly chooses to use the "Block Sharing" feature). What Warp currently sends in regard to telemetry is listed here: https://docs.warp.dev/getting-started/privacy#exhaustive-telemetry-table https://docs.warp.dev/getting-started/privacy#exhaustive-tel....
- deleted 4y ago
  [deleted]
- bhauer 4y ago
  Still too much telemetry in my opinion. Is it possible to opt out, perhaps for a price?
  - alokedesai 4y ago
    We are actively working on making telemetry opt out. We are very sympathetic to concerns about telemetry and data collection and try to be as transparent as possible about what we collect and why. We only collect metadata and never command input or output (you can see the full list of events we track here: https://docs.warp.dev/getting-started/privacy#exhaustive-telemetry-table https://docs.warp.dev/getting-started/privacy#exhaustive-tel.... We initially required telemetry for all users while in beta so that we could have a better understand of usage patterns and improve the product in its early stages. As we mature, we are able to better extrapolate from a larger sample size without requiring telemetry.
    - user3939382 4y ago
      It’s a checkbox/boolean whose persisted value is checked in an if statement on your network calls. It shouldn’t be opt out in the first place, it should be opt in.
  - danny_warp 4y ago
    Yes! We are working on opt-out for telemetry.
gtm1260 4y ago
This is awesome
0xbadcafebee 4y ago
> This post is about why terminal-based input seems stuck in the 80s It's actually more 60s/70s, when the first terminals, command-line prompts, and shells were built. The reason why it's stuck there is technology has only improved iteratively rather than revolutionarily. The "lets add another layer of abstraction" form of innovation, rather than outside-the-box thinking and reinvention. The fact that we still write software by hand using lines of source code in a text editor is pretty ridiculous to me. It's not that far removed from punch cards.
- maximus-decimus 4y ago
  What would you prefer it to be? Audio recording of spoken words? Diagrams like Labview?
  - 0xbadcafebee 4y ago
    Ideally? That holographic interface Tony Stark uses. I would settle for a combination of SolidWorks and Visual Basic. SoldWorks to model and visualize the whole thing, pick it apart, run it. Visual Basic to assemble DCOM objects, add simple logic, design an interface. Export/import SolidWorks models and connect them to new models to re-use a whole "machine". Keep a corporate library of "machines", import one to do what you need, fork it and make a new one if it doesn't do what you want.
    - maximus-decimus 4y ago
      So a holographic LabView.
  - solarkraft 4y ago
    Code is really a tree of stuff. There are are somewhat more powerful editing paradigms for trees than bare text. The editor I'm imagining looks and works a lot like your typical code view, but has a better understanding of the semantics and makes things there are keyboard shortcuts for more visible. From the top of my head: First-class code folding and commenting and actions primarily on blocks rather than lines. e.g. if you disable ("comment out") an if-statement, either disable the whole block or the wrapping of the inside code with the condition. It's very rare that you want to do something in between and in textually based languages this action is much harder than it needs to be without producing a syntax error. An important part of GUI design is to avoid the possibility for invalid states, but text-based code editing in its current form produces a lot of them, totally unnecessarily and annoyingly so, in my opinion. I'm sure that tools with features like this already exist, but they're certainly not popular.
hprotagonist 4y ago
if $EDITOR is properly configured, C-x C-e and hey presto, all is well for complex commands.
- forgotpwd16 4y ago
  The fact that such a command exists is an argument that terminal input is indeed bad.
  - hprotagonist 4y ago
    i bother with it very rarely. readline is more than enough.
  - bombolo 4y ago
    readline is used by more than one kind of shell. I'd actually like if ipython used it.
    - hprotagonist 4y ago
      it does.
lordleft 4y ago
Guys, it doesn't matter if you can edit terminal input in vim. If there's a way to do it in an even more ergonomic / user-friendly way, that's not intrinsically a bad thing. This entire comment thread makes us sound like tech-grognards. Warp's pricing model is a whole other issue though.
- Arnavion 4y ago
  And who decided that Warp's method is more ergonomic / user-friendly with such objective proof that it cannot be argued over?
  - password1 4y ago
    Maybe some user research? It can be argued for sure though, everything can be argued over all the time forever.
- bee_rider 4y ago
  It isn’t a bad thing that somebody is trying to find an alternative to the standard terminal. Good luck to them! But they decided to write a whole blog post making up problems about peoples’ current workflow. People are naturally going to point out that they don’t suffer from these problems. If warp didn’t want it to matter, they could have not brought it up I guess.
  - coldtea 4y ago
    >But they decided to write a whole blog post making up problems about peoples’ current workflow. Not really, those are problems with current workflows. >People are naturally going to point out that they don’t suffer from these problems. They do, they just work around them or are used to them.
    - hansvm 4y ago
      > They do, they just work around them or are used to them. That's trivially true for any "problem" that people "don't suffer from," and it's not that interesting. Problem: Input editing in the shell is hard if you can't remember the appropriate keyboard shortcuts and don't use the relevant features. Workaround: Remember keyboard shortcuts and use them. Blog-proposed workaround: Download our app. If people want to use their app then that's fine and dandy, but I don't think it's reasonable to frame my experience as being hampered by a problem that the app would solve when my workflow is not in fact hampered by it. It's acceptable and normal for a tool to not have a universal audience.
shadeslayer_ 4y ago
I have been using Warp for the past couple of days and the autosuggestions when I'm working over SSH are pretty nifty, it probably saves me a fair amount of time everyday. Making a login required is absolutely unnecessary, though.
kevdoran 4y ago
Warp looks fantastic! It looks like it's not OSS yet but they're considering it? https://github.com/warpdotdev/Warp/blob/main/LICENSE https://github.com/warpdotdev/Warp/blob/main/LICENSE
- alokedesai 4y ago
  Thank you for your kind words! We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client. We want to make sure we get this right, both for our users and for Warp. Our current best-guess on how we'd do this is a more restrictive license that * allows for verifying security and privacy * allows individuals to build and tweak Warp * prevents another company from starting a commercial enterprise off of it We'd love more thoughts here though! Feel free to join the discussion at https://github.com/warpdotdev/Warp/discussions/400 https://github.com/warpdotdev/Warp/discussions/400 if you're interested.
  - bombolo 4y ago
    So many words to write "it will never be open source"
chungy 4y ago
Emacs's term-mode already solves all of these supposed problems. I say supposed because they're really not all that big of a deal. OK, bash making it difficult to go backwards to previous lines is... annoying, at least until you press C-x C-e and do what you want anyway. The use of a mouse for something text-centered is pretty much foreign to me, too.
- tmtvl 4y ago
  And of course for anyone who doesn't like term there's always shell and eshell. And if neither of those will suffice vterm is readily available from MELPA.
deanmen 4y ago
Just use `M-x shell` in emacs.
- forgotpwd16 4y ago
  Indeed. What the article describes is Emacs' terminals. Can also use `eshell` (albeit non-POSIX shell) for an even better experience.
giantdude 4y ago
This is 'Hacker News'. Hackers like open source.
thefilmore 4y ago
Because you haven't `set -o vi`.
terminal_d 4y ago
A lot of macOS users are suckers for any sort of themed-up applications that can be replicated in their normal setups without any extra software, had they just bothered to RTFM.
- wmf 4y ago
  You're not wrong but historically a lot of money has been made selling thing to people who don't RTFM. I mean a lot.
  - smoldesu 4y ago
    Now for the real trick: if Apple obfuscates the manual and taxes the manual-sellers, then they have a real moneymaker on their hands!
brenns10 4y ago
A lot to be said about this - setting aside the privacy/login/pricing stuff, I think the problems and solutions here are vastly overstated. Yeah, terminal input is odd at times. Doubly so if your main prior experience is entering text into HTML textareas. There's a learning curve, but there's a benefit to tackling that curve. For one, you get readline editing, which is _far_ more powerful than the textarea comparison, and it's customizable. For another, if you need to use your editor to manage a larger command, you have that exact option (see Ctrl-X Ctrl-E in bash/readline). That editor can be vim, or it could be your pimped out VSCode with Copilot. Bash doesn't care. When you think about it, that's a good 70% of the article's complaints resolved. Trouble navigating through lines of command input? Learn your readline keybindings, or just pop it open in your editor of choice, which also grants you syntax highlighting and whatever else. The other 30% of what article proposes are pretty decent ideas. Why _isn't_ there a way to hover over a command and see a snippet from its manual page, or to hover over a command-line flag or option, and see the data from the manual page? We have bash-completion which can provide us command-specific completion, what about docs? Many new features can be added to the current architecture. For example, OSC 52 allows terminal apps to send data to the clipboard so long as the terminal emulator supports it. I don't see why similar extensions couldn't enable applications to annotate text with documentation, etc. But that doesn't require the terminal to take over all the line editing: it's just incremental improvement to the current system. And that's where I think this article and approach are wrong. Maybe it works with the user's shell, but what about Python? GDB? Or the myriad other command line tools I use on a daily basis? As it is now, my terminal is responsible for being the best "terminal emulator" possible. It handles input, draws to my screen, and does it fast. It doesn't need to concern itself with supporting GDB: it is a terminal, and that's that. I'd rather not see these layers get smooshed. Let's focus on improving the current system so that GDB, readline, and the other pieces of the puzzle can incrementally improve the situation.
CharlesW 4y ago
What do heavier terminal users think of Warp's philosophy vs. Fig's (which I've found useful as a relatively-light terminal user)? https://fig.io/ https://fig.io/
- brendanfalk 4y ago
  Founder of Fig here. For context, Fig integrates with your existing terminal and shell. A few things we've found: 1. Developers are understandably opinionated about their terminal/shell setup. It's a matter of personal productivity. 2. We have noticed a general trend of more terminal use happening in IDE, not a standalone terminal. 3. Most terminal "collaboration" happens asynchronously not synchronously (e.g. shared scripts, CLIs, secrets etc as opposed to live terminal sharing) 4. Most of the collaboration happens at the shell level not the terminal level Given the above, we made the conscious conscious decision not to build our own terminal. Happy to elaborate more
  - jasonjmcghee 4y ago
    > We have noticed a general trend of more terminal use happening in IDE, not a standalone terminal. This. I barely use terminal outside of Jetbrains, and heard similar things from other devs. And people who live in vim/emacs (I used to live in vim)- I would be surprised if they'd pickup something that might interfere with their setup, like tmux or special plugins etc. (forcing login stuff aside- assuming that'll be removed at some point) But maybe warp folks will find a way to play nice with everything, or be simply too useful to not use.
einherjae 4y ago
A lot of the complaints here can be solved by knowing that C-x e will drop you from bash into emacs to edit your current line, which then gives you any bells and whistles you’ve configured in emacs. Bonus is that this is generally available and doesn’t require a newfangled set of tools.
- niemandhier 4y ago
  15 years and I never heard of that! Cool featue.
beej71 4y ago
At the simplest level, this reminds me of input in C64 BASIC. You could hit RETURN anywhere on on any line and that line would get parsed as if you'd just types it in. You could cursor around, edit previously-entered lines, and so on. It was pretty neat.
kelseyfrog 4y ago
Seventy-five to one hundred percent of the author's complaints are addressed by the `fc` command and I'm surprised it hasn't been mentioned yet. Fc opens $EDITOR and upon exiting executes the saved contents. It's great for editing a complex command, but perhaps a tad obscure.
- Arnavion 4y ago
  Also bash supports Ctrl-X + Ctrl-E to open $EDITOR to edit the current prompt.
  - quesera 4y ago
    In vi mode (i.e. after "set -o vi") in bash or zsh, you can open $EDITOR on the current prompt contents with: Esc, then v
- davesmylie 4y ago
  certainly pretty obscure. I'd been mucking around in shells for 20+ years before I found it. Now it's part of my core set of commands used constantly.
- frankjr 4y ago
  If using iTerm2, you can also press Shift+Cmd+. and it will open a small window/prompt where you can type your command while still interacting with the terminal.
- deleted 4y ago
  [deleted]
- bitwize 4y ago
  M-x shell in Emacs also covers most of the complaints. Galaxy brain: M-x eshell. Use regular Emacs commands from the shell! Define functions in Emacs Lisp, use them as shell commands!
steve1977 4y ago
set -o emacs?
aap_ 4y ago
On plan 9 you can easily edit any text in a window. Seems like a sensible idea.
bitwize 4y ago
$27 million in A round funding for a terminal emulator, folks. And it's written in Rust! For Macs only! All it needs is to detect and respond to the state of your gut bacteria and it'd be truly peak Hackernews. Good thing they got that funding a few months ago instead of now, when there's far less VC money sloshing around and the Juicero of the command line looks like a far less enticing proposition.
motbus3 4y ago
learn vi set -o vi You are free
ed25519FUUU 4y ago
What I don’t like is the non-ergonomic way that text scrolls. If three lines appear then the cursor is moved down three lines. I’m always craning my neck to try and find where the input cursor is just to reset it constantly to the “top” of the screen. I’d love it if I could just “glue” it to the bottom or top so output doesn’t change its location constantly.
- kevin_thibedeau 4y ago
  You can use a VT100 escape to force the prompt to the bottom by moving the cursor to line 999 col 0: \[\033[999;0f\]
biftek 4y ago
A lot of those complaints are non issues with the default terminal in MacOS. Option + mouse click moves the cursor to where ever, control+a|e move to the beginning or end of the line, option+arrow jumps words, and the arrows navigate up and down lines just fine... What am I missing?
- wmf 4y ago
  You're missing the fact that those shortcuts are not discoverable.
  - quesera 4y ago
    An oddball custom Terminal is not discoverable either. There's no substitute for learning the tools. If you ever find yourself thinking "weird that there's no way to X", in a shell or editor, you're probably wrong.
  - biftek 4y ago
    And this app is more discoverable? Those shortcuts also work in any text field in MacOS, they aren't proprietary to just a terminal.
  - shric 4y ago
    Almost nothing in a shell is discoverable. Are these discoverable? ls, cat, $?, $@, <, >, >>, $(cmd), ${foo}, $((2+2)) If you can take the time to learn these (if not, why are you using a terminal?), then you can learn some shortcuts without them being "discoverable".
otikik 4y ago
I am probably not going to try this, but I am glad it exists.
AndriyKunitsyn 4y ago
The developers seem to be proud that their shell is “Rust-based”, they write it several times on the main page. But why would I care what a closed-source application is made with? Sorry if it’s blunt, but I just don’t get it.
- dack 4y ago
  I think it's signaling that it's probably modern, fast, and that the authors care about correctness. I think the customer has to have bought-in to the Rust hype for that to work, but since it's a developer tool, I can see how it might attract some.
MrWiffles 4y ago
I like the idea of Warp, but I just can't get past the whole "login required to use a terminal" thing. If you force a login to use your closed-source app, beta or not, I'm sorry, but I can't take any commitment to privacy you make seriously whatsoever. No matter how well-intentioned you may be. That well's been poisoned beyond redemption by far worse people than you and there's just no going back. Now if that login required barrier was removed, I'd at least be willing to give it a try. May not switch, but I'd be willing to give it a chance. But as it stands? Hard pass.
- shric 4y ago
  It also doesn't support/play nice with[1] tmux, which was a hard deal breaker for me. [1] https://github.com/warpdotdev/Warp/discussions/501 https://github.com/warpdotdev/Warp/discussions/501
- Brian_K_White 4y ago
  "No matter how well-intentioned you may be." ... and they should already know all that, and there is really no believable excuse for not knowing all that already, and I don't for a second believe they don't. So, really there is not even any doubt to give any benefit of the doubt like "even if you're well intentioned". Passed that already.
qbit42 4y ago
As a casual terminal user, I have found Warp to be a nice improvement over standard terminals. Although most of the issues raised in this article can be addressed with various shortcuts, it is nice to not have to remember these when I only pull up the terminal a couple times a week.
- golang-gopher 4y ago
  Didnt read their article. I have used warp to try it out like an idiot and realized that many of the things people have mentioned here were just things I did not know. Such as ALT + CLICK to bring my carot where I need it and CTRL+X and CTRL+E to use vim to edit more advanced stuff. I always use CTRL+A and CTRL+E on any shell to jump to front or back but I think I have enough information from this hackernews thread to uninstall warp.
nathias 4y ago
your problem with terminal is that you don't grok vi
ksherlock 4y ago
Let me mention MPW - The Macintosh Programmer's Workshop for classic MacOS. The shell was a text editor, just like the text editor for editing code. When you hit enter (or command-return) it evaluated the current line or selection. Command results were included in the document. (This was strictly a dumb terminal so there were no vt100 escape codes or such to mess up the display) If you were confused about the command arguments you could run commando (or use … as an argument) to bring up a GUI to select the flags. The Eddie text editor for BeOS and now MacOS X/XI/XII/XIII has a similar text-editor/shell hybrid. http://www.el34.com http://www.el34.com
- robterrell 4y ago
  Also -- BBEdit's "Shell Worksheet" is the MPW Workshop for today. I use it for so much every day. No commando, though, that was so great.
shric 4y ago
Dark pattern #1: Allowing the user to download the app and only then requiring the user to login/signup. This is because you know very well almost nobody will bother to try your terminal if you make it clear you require a login up front. But if they've gone to the trouble of downloading it, dragging it to Applications and running it, then maybe they'll go all the way. Dark pattern #2: On sign-up, you "agree to our terms of service" but then you have the gall to say, on unsubscribe: "you are currently subscribed to our opt-in messaging. Do you want to remove yourself from opt-in messaging?" Agreeing to a 17 page terms of service document might be technically "opting in" to messaging (spam), but it sure isn't in spirit. Opting in is when you click on a, previously unchecked, check box that has "I'd like to receive marketing from you". I'm sure there's plenty more but I uninstalled it already.
- alexruf 4y ago
  Agree. When I stared reading the article I was exited at first. I generally agree that terminals have a lot of legacy issues from the past and could definitely use some innovation. But I don’t see the point why a terminal should require internet-connection at all. There is absolutely no reason any of the features Warp mentions, couldn’t be implemented in a way to work completely offline. Good luck, but I don’t think any people using terminals as their daily drivers will ever use a product like this.
- quesera 4y ago
  I'm going to go straight to "Any terminal or shell which initiates network connections as part of its core execution model, is a huge no from me". Think about all the things you type into a shell, via a terminal!
  - green_on_black 4y ago
    Stable Diffusion hentai plots.
  - SAI_Peregrinus 4y ago
    The one exception I'd give is for actual remote terminals (e.g. old-style TTYs), which are inherently making some sort of network requests. SSH (Secure SHell) would be much less useful if it couldn't make network requests as part of its core execution model! Of course for a local terminal emulator no such requests are necessary.
sbbr 4y ago
golem> ed ? help ? ? ? quit ? exit ? bye ? hello? ? eat flaming death ? ^C ? ^C ? ^D ?
VWWHFSfQ 4y ago
Let's be honest here, nobody is using this warp terminal as long as it's closed-source and especially not when it has built-in tracking. To the warp terminal developers: I'm sure your terminal program is great, but stop posting this content-marketing stuff here. It's not your audience.
- origin_path 4y ago
  "nobody is using this warp terminal as long as it's closed-source" Lots of developers use Terminal.app, so that clearly isn't a real problem. There's no obvious reason why developers would be willing to buy a closed source IDE, operating system or cloud services but not a terminal emulator. I think people are reacting more to the login requirement than anything else.
- golang-gopher 4y ago
  whats hilarious, is on their discord, they want this upvoted. I dont think they realize this is bad marketing for this article to be upvoted. " We're launching our new and improved input editor. We just posted our article on the history of the terminal input, and how we could innovate on it.. We would appreciate if you could show the post some love. "Why is the terminal input so weird?” (navigate to HN and go to the “new” page and vote / leave a comment - we aren’t linking to it here because that can trigger HN’s moderation filters)" Upvote this!!!
- qrio2 4y ago
  Seconded, this product is like an anti-tool.
- forgotpwd16 4y ago
  The program may be great, may be bad, but the article is interesting when considered in the topic of terminal input and ergonomics.
eointierney 4y ago
I'm only a relative newbie but emacs Literate programming in org-mode with babel and magit and () is Still weird but so much more than a terminal
deleted 4y ago
[deleted]
qrio2 4y ago
Bro please stop shilling your stupid terminal replacement. Nobody here wants this. Almost everybody here believes you need to get comfortable working in the STANDARD TERMINAL
Brian_K_White 4y ago
If I were able to stomach this idea at all, I would just replace my terminal with Alexa or Gooogle Assistant not this.

110 points by zachlloyd 4y ago

Wow. The intent and the idea is so cool. But it's so clearly been touched by VC funding, it almost makes me wonder if this is a (really expensive) gag. Requires an account? Check. Crashes IMMEDIATELY upon opening? Check. Doesn't support any tool I use (e.g. FZF, key-bindings, etc)? Check. Spammy "iS tHe tErMiNaL oN lIfE sUpPoRt?" blog post? Check. Do they even know their target market is mildly allergic to all of the above? Yikes.

raydev 4y ago

I wonder how many people upset about Warp here also use VS Code and don't bother turning telemetry off.

smoldesu 4y ago
If you're using Warp it's likely you're not taking your privacy seriously anyways. It only supports MacOS, which has telemetry like OCSP that is impossible to disable.

apetresc 4y ago

I can edit the terminal input line with full vim-mode in my shell (zsh). In fact, in normal mode I can even hit 'v' and edit the line in a full vim session to zip around however I want, do completions, etc. It's pretty close to the platonic ideal method of input I could imagine.

ploum 4y ago
I’m also using vim mode in zsh with simply "bindkey -v". I’m interested by your "v" as full vim session shortcut. Do you mind sharing the config?
- apetresc 4y ago
  It's this section of my .zshrc here: # edit long commands autoload -U edit-command-line bindkey -M vicmd v edit-command-line That `edit-command-line` autoload script is part of zshcontrib and should be installed by default on any recent zsh distribution. I've never encountered a server I've ssh'ed into that didn't have it. Enjoy :)
  - ploum 4y ago
    Thanks. Also learned about "fc" to edit the last command entered.
  - ploum 4y ago
    If someone from the future read this, I needed to add one more line to make it work: autoload -U edit-command-line zle -N edit-command-line bindkey -M vicmd v edit-command-line
puffoflogic 4y ago
The biggest problem with zsh's vim mode is it's actually vi mode. I constantly want "])" and "aw" motions but they're not implemented :( But, like, this is obviously an entirely different class of problem from TFA, which is a skill issue.
terminal_d 4y ago
This is also available in bash. In emacs input mode (aka the default) one can press C-x C-e to edit the current command in an editor. `v` is also available in vi input mode.

smoldesu 4y ago

As much as I'd like to encourage the rethinking of input methods, any terminal with a "Pricing" page is an instant nope from me. My current terminal is Open Source and while it's not perfect, it's also Free. That matters more to me than mouse input or IDE autosuggestions. If you're going to treat Linux users as a second-class citizen and charge for corporate usage, who are you hoping your target audience will be? Frankly, I don't ever see this replacing iTerm 2 for most Mac developers. I wish you luck, but your product in it's current state is confusing to me. fish solves most of these issues for me and it runs on all my devices, free. All I'll say is that your competition is stiff.

danny_warp 4y ago
The app is 100% free for any and all individuals. The business plan is to create collaborative and cloud-based features that businesses will be willing to pay for. Please check out our pricing page to learn more. Please note that our business model is not about collecting and monetizing any of your personal data. https://www.warp.dev/privacy https://www.warp.dev/privacy
- KronisLV 4y ago
  > The business plan is to create collaborative and cloud-based features that businesses will be willing to pay for. You know what, that is fair. I know a lot of folks take an issue with software that is monetized and many are jumpy about software that might rugpull them and lock certain features behind a paywall some time down the line, or look into more aggressive forms of monetization, but at the same time a lot of software would probably be better made if it had stable financial backing. I'll probably keep using the most boring terminal setup that's possible just for the sake of not being an early adopter (which is just an excuse because I don't have a Mac), but I'm curious to see how this will play out in the long term, so good luck with your endeavor! > Please check out our pricing page to learn more. Here's the direct link: https://www.warp.dev/pricing https://www.warp.dev/pricing And to save folks a click: Individual A modern terminal experience for individuals. Download now! Free Includes - Block Creation - A.I. Command Search - Workflows - Modern input text editing Team Advanced collaboration and support for teams. Coming soon. Pricing TBD Everything in Individual, Plus - Shared team configurations - Shared team workflows - Real-time terminal sharing - Shared terminal notebooks Enterprise Security, compliance, and flexible deployment. Coming soon. Pricing TBD Everything in Team, plus - Advanced security and compliance - Advanced team deployment - Integration with internal tools

zokier 4y ago

Although I don't like terminals, I think the article overstates the problems to significant degree. The fact that text editors running in terminal still manage to have "ide-like" experience (including mouse input!) proves that you can do a lot with terminals. I still think that trying to move beyond terminals is good idea, but it's important to distinguish what is impossible, and what is just ugly/hacky to do.

alokedesai 4y ago
Aloke from the Warp team here--you're totally right that some of these features (syntax highlighting) can be accomplished within the terminal using an editor. In a traditional terminal--you'd have to spend time configuring your shell to get this to work instead of getting these features by default. Some of these features are near-impossible given the current terminal-shell abstraction, however. For example, a traditional terminal has no concept of command input/output, which means that it can't suggest a next command to run based on the output of the previous command.
- vimda 4y ago
  > it can't suggest a next command to run based on the output of the previous command thefuck (https://github.com/nvbn/thefuck#how-it-works https://github.com/nvbn/thefuck#how-it-works) does exactly that...
  - alokedesai 4y ago
    We collaborated with thefuck to build our version of this :) TF is slightly different in that they actually _rerun_ your last command to get the output since they don't have access to command output
- zokier 4y ago
  > For example, a traditional terminal has no concept of command input/output, which means that it can't suggest a next command to run based on the output of the previous command. Neither does wayland or whatever. Point being that you can treat terminals as dumb character cell grid display with slightly wonky input mechanism and get quite far ignoring/working around all the traditional line-oriented stuff.

ploum 4y ago

People who do not understand things are poised to reinvent them badly. The post manage to analyse terminal input without having acknowledging readline. So yeah, they have no idea what they are talking about. https://www.masteringemacs.org/article/keyboard-shortcuts-every-command-line-hacker-should-know-about-gnu-readline https://www.masteringemacs.org/article/keyboard-shortcuts-ev...

sureglymop 4y ago
They fail to understand that this isn't a problem of the terminal at all... The terminals only job is to display output and to pass through input. They could write an "interactive shell" with mouse support that implements all those features and it would run in any pre existing terminal. They could even make this work with existing shells and it would work over ssh ect. Nothing against innovation but this is the wrong approach imo.
brenns10 4y ago
I also disagree with this article's approach, but it seems pretty disingenuous to say that they don't understand terminal input because they didn't mention readline. After all, this is a blog post on the site for a terminal implementation. They'd have to be unbelievably ignorant to not be aware of the role of readline here. They're not writing a technical deep dive, they're presenting their vision for a different approach. I think that vision is flawed but I'm not going to grade them on how deep they get into implementation details.

mostlysimilar 4y ago

I bit and was curious to try Warp. Downloaded it and it immediately made a request to a Google domain and then forced a sign-up window on me. I clicked their "why do we require an account" FAQ and the answer is "we think there are features that are better with a login." Absolute no from me, even if their terminal truly is better and innovative.

drcongo 4y ago

I have one question about terminal input that I cannot work out how to work out. The setup: I'm on a Mac, I use iTerm for my terminal, Fish for my shell, and most often I'm inside a docker container also running Fish and using iPython. The question: When I Ctrl+W to delete a word in a Fish prompt, what counts as a word is different to what counts as a word in iPython. For instance, Ctrl+w at the end of this string `test.func('param1', 'param2')` produces... Fish: test.func('param1', 'param2' iPython: test.func('param1', Hit Ctrl+w again, and you get... Fish: test.func('param1', ' iPython: all gone. This causes me to over delete in iPython many, many times per day. I'm guessing that the rough flow of the delete word signal is iTerm -> Fish -> iPython and that iPython is the thing that's being overzealous?

theblazehen 4y ago
> I'm guessing that the rough flow of the delete word signal is iTerm -> Fish -> iPython and that iPython is the thing that's being overzealous? Almost correct. Once you launch iPython, Fish is out of the picture until you quit iPython. However yes iPython does handle Ctrl-W differently from your shell
- drcongo 4y ago
  Thanks, that helps narrow it down. Next to work out how to make it behave more like fish, as Ctrl+w deleting the entire string `test.func('param1',` seems like madness to me.
fratajcz 4y ago
That bothered me too, the default function for Ctrl-W in ipython is unix-word-rubout from python-prompt-toolkit [1], which uses spaces for word boundaries. You can rebind it to backward-kill-word so it uses "not a letter nor a digit" as a word boundary. Here's a gist with my config (also binds shift-left/right arrow to move to previous space instead of visual select): https://gist.github.com/fratajczak/64e32421a43d3b8194d0409ce300518a https://gist.github.com/fratajczak/64e32421a43d3b8194d0409ce... [1]: https://github.com/prompt-toolkit/python-prompt-toolkit/blob/65c3d0607c69c19d80abb052a18569a2546280e5/src/prompt_toolkit/key_binding/bindings/named_commands.py#L386 https://github.com/prompt-toolkit/python-prompt-toolkit/blob...

puffoflogic 4y ago

TL;dr. In zsh (vi mode) I simply press shift-v and I am dropped into my $EDITOR with my current input loaded into a buffer. Of course I rarely need to do this because zsh vi mode covers 99% of my requirements. So, my tldr for an article I didn't finish reading: someone doesn't know how to use their tools and instead of learning they jumped on the internet to complain, and/or sell me a solution or something, idk.

nsdarren 4y ago
What's the point of this comment other than being snarky/attempting to show off? You should reflect on it, because this would be a better place if people like you just didn't bother replying. Maybe you don't find it valuable because your setup and mad vi skills offer you an alternative (which I'm very sure is just as feature-rich as what is described in the post, which you didn't read). Isn't it obvious how a more accessible solution might be useful to some people? I for one welcome the efforts of the Warp team to improve terminal UX.
Stranger43 4y ago
Interestingly for me this dont work with .zsh out of the box on my mac(i run a deliberately minimalist .zsh) what did you actually do to enable it. esc -> v does work both with bash and mksh on ubuntu with stock config but not out of the box with zsh on my macbook so i suspect there is something missing im my one line .zshrc file. Capital V is an actual vim command btw triggering linewise visual mode and that does somewhat seem to actually seem to be the functionality of shift-v by default in zsh.
- quesera 4y ago
  > what did you actually do Enable vi mode (usually in .zshrc but you can test from the command line): set -o vi Invoke $EDITOR on the current command line: ls -la /tmp<Esc><v> That's Escape, then the lowercase v key (sequentially, not together) You can use up-arrow to go through command history, reach the one you want to rerun with modifications, then press Esc, v.
  - 4y ago

vander_elst 4y ago

TO better understand the architecture, how will this work if I want to use the shell in vi mode? IIUC that would not be possible with their setup, right? Warp would need to implement a vi mode, correct? Is it possible to work with vim in warp?

alokedesai 4y ago
You can launch vim within Warp without any problems, but vi/vim mode for the line editor itself isn't supported in Warp just yet. You're correct that this is because we'd need to implement VI mode ourselves (tracking issue here [1] if you are interested). This is the tradeoff of building our own editor instead of using the shell's--we can build features that wouldn't be possible in the shell directly but it requires us to build features that already exist in the shell from scratch. So far, this tradeoff has been well-worth it to build what we think is a better experience when using the terminal. [1] https://github.com/warpdotdev/Warp/issues/159 https://github.com/warpdotdev/Warp/issues/159
- vander_elst 4y ago
  Thanks for the answer! Still curious, how does vim work in Warp? Do you know what process are currently running and then you stop buffering the chars and you pass them directly to the process in foreground? I didn't read the code, but from the article it seemed that you pass the text to the shell only when pressing enter, I think in vi(m) you want to do it the whole time (?). If I want to insert something I just type `isomething to insert<Esc>`. How does this work in Warp? What happens if I put the process in background and then in foreground again?

danny_warp 4y ago

Warp currently requires a login to enable cloud-based features, like A.I. Command Search and Block Sharing, along with team features on the roadmap. In case there was any confusion, Warp never sends the contents of terminal commands and outputs to our servers (unless a user explicitly chooses to use the "Block Sharing" feature). What Warp currently sends in regard to telemetry is listed here: https://docs.warp.dev/getting-started/privacy#exhaustive-telemetry-table https://docs.warp.dev/getting-started/privacy#exhaustive-tel....

deleted 4y ago
[deleted]
bhauer 4y ago
Still too much telemetry in my opinion. Is it possible to opt out, perhaps for a price?
- alokedesai 4y ago
  We are actively working on making telemetry opt out. We are very sympathetic to concerns about telemetry and data collection and try to be as transparent as possible about what we collect and why. We only collect metadata and never command input or output (you can see the full list of events we track here: https://docs.warp.dev/getting-started/privacy#exhaustive-telemetry-table https://docs.warp.dev/getting-started/privacy#exhaustive-tel.... We initially required telemetry for all users while in beta so that we could have a better understand of usage patterns and improve the product in its early stages. As we mature, we are able to better extrapolate from a larger sample size without requiring telemetry.
  - user3939382 4y ago
    It’s a checkbox/boolean whose persisted value is checked in an if statement on your network calls. It shouldn’t be opt out in the first place, it should be opt in.
- danny_warp 4y ago
  Yes! We are working on opt-out for telemetry.

gtm1260 4y ago

This is awesome

0xbadcafebee 4y ago

> This post is about why terminal-based input seems stuck in the 80s It's actually more 60s/70s, when the first terminals, command-line prompts, and shells were built. The reason why it's stuck there is technology has only improved iteratively rather than revolutionarily. The "lets add another layer of abstraction" form of innovation, rather than outside-the-box thinking and reinvention. The fact that we still write software by hand using lines of source code in a text editor is pretty ridiculous to me. It's not that far removed from punch cards.

maximus-decimus 4y ago
What would you prefer it to be? Audio recording of spoken words? Diagrams like Labview?
- 0xbadcafebee 4y ago
  Ideally? That holographic interface Tony Stark uses. I would settle for a combination of SolidWorks and Visual Basic. SoldWorks to model and visualize the whole thing, pick it apart, run it. Visual Basic to assemble DCOM objects, add simple logic, design an interface. Export/import SolidWorks models and connect them to new models to re-use a whole "machine". Keep a corporate library of "machines", import one to do what you need, fork it and make a new one if it doesn't do what you want.
  - maximus-decimus 4y ago
    So a holographic LabView.
- solarkraft 4y ago
  Code is really a tree of stuff. There are are somewhat more powerful editing paradigms for trees than bare text. The editor I'm imagining looks and works a lot like your typical code view, but has a better understanding of the semantics and makes things there are keyboard shortcuts for more visible. From the top of my head: First-class code folding and commenting and actions primarily on blocks rather than lines. e.g. if you disable ("comment out") an if-statement, either disable the whole block or the wrapping of the inside code with the condition. It's very rare that you want to do something in between and in textually based languages this action is much harder than it needs to be without producing a syntax error. An important part of GUI design is to avoid the possibility for invalid states, but text-based code editing in its current form produces a lot of them, totally unnecessarily and annoyingly so, in my opinion. I'm sure that tools with features like this already exist, but they're certainly not popular.

hprotagonist 4y ago

if $EDITOR is properly configured, C-x C-e and hey presto, all is well for complex commands.

forgotpwd16 4y ago
The fact that such a command exists is an argument that terminal input is indeed bad.
- hprotagonist 4y ago
  i bother with it very rarely. readline is more than enough.
- bombolo 4y ago
  readline is used by more than one kind of shell. I'd actually like if ipython used it.
  - hprotagonist 4y ago
    it does.

lordleft 4y ago

Guys, it doesn't matter if you can edit terminal input in vim. If there's a way to do it in an even more ergonomic / user-friendly way, that's not intrinsically a bad thing. This entire comment thread makes us sound like tech-grognards. Warp's pricing model is a whole other issue though.

Arnavion 4y ago
And who decided that Warp's method is more ergonomic / user-friendly with such objective proof that it cannot be argued over?
- password1 4y ago
  Maybe some user research? It can be argued for sure though, everything can be argued over all the time forever.
bee_rider 4y ago
It isn’t a bad thing that somebody is trying to find an alternative to the standard terminal. Good luck to them! But they decided to write a whole blog post making up problems about peoples’ current workflow. People are naturally going to point out that they don’t suffer from these problems. If warp didn’t want it to matter, they could have not brought it up I guess.
- coldtea 4y ago
  >But they decided to write a whole blog post making up problems about peoples’ current workflow. Not really, those are problems with current workflows. >People are naturally going to point out that they don’t suffer from these problems. They do, they just work around them or are used to them.
  - hansvm 4y ago
    > They do, they just work around them or are used to them. That's trivially true for any "problem" that people "don't suffer from," and it's not that interesting. Problem: Input editing in the shell is hard if you can't remember the appropriate keyboard shortcuts and don't use the relevant features. Workaround: Remember keyboard shortcuts and use them. Blog-proposed workaround: Download our app. If people want to use their app then that's fine and dandy, but I don't think it's reasonable to frame my experience as being hampered by a problem that the app would solve when my workflow is not in fact hampered by it. It's acceptable and normal for a tool to not have a universal audience.

shadeslayer_ 4y ago

I have been using Warp for the past couple of days and the autosuggestions when I'm working over SSH are pretty nifty, it probably saves me a fair amount of time everyday. Making a login required is absolutely unnecessary, though.

kevdoran 4y ago

Warp looks fantastic! It looks like it's not OSS yet but they're considering it? https://github.com/warpdotdev/Warp/blob/main/LICENSE https://github.com/warpdotdev/Warp/blob/main/LICENSE

alokedesai 4y ago
Thank you for your kind words! We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client. We want to make sure we get this right, both for our users and for Warp. Our current best-guess on how we'd do this is a more restrictive license that * allows for verifying security and privacy * allows individuals to build and tweak Warp * prevents another company from starting a commercial enterprise off of it We'd love more thoughts here though! Feel free to join the discussion at https://github.com/warpdotdev/Warp/discussions/400 https://github.com/warpdotdev/Warp/discussions/400 if you're interested.
- bombolo 4y ago
  So many words to write "it will never be open source"

chungy 4y ago

Emacs's term-mode already solves all of these supposed problems. I say supposed because they're really not all that big of a deal. OK, bash making it difficult to go backwards to previous lines is... annoying, at least until you press C-x C-e and do what you want anyway. The use of a mouse for something text-centered is pretty much foreign to me, too.

tmtvl 4y ago
And of course for anyone who doesn't like term there's always shell and eshell. And if neither of those will suffice vterm is readily available from MELPA.

deanmen 4y ago

Just use `M-x shell` in emacs.

forgotpwd16 4y ago
Indeed. What the article describes is Emacs' terminals. Can also use `eshell` (albeit non-POSIX shell) for an even better experience.

giantdude 4y ago

This is 'Hacker News'. Hackers like open source.

thefilmore 4y ago

Because you haven't `set -o vi`.

terminal_d 4y ago

A lot of macOS users are suckers for any sort of themed-up applications that can be replicated in their normal setups without any extra software, had they just bothered to RTFM.

wmf 4y ago
You're not wrong but historically a lot of money has been made selling thing to people who don't RTFM. I mean a lot.
- smoldesu 4y ago
  Now for the real trick: if Apple obfuscates the manual and taxes the manual-sellers, then they have a real moneymaker on their hands!

brenns10 4y ago

A lot to be said about this - setting aside the privacy/login/pricing stuff, I think the problems and solutions here are vastly overstated. Yeah, terminal input is odd at times. Doubly so if your main prior experience is entering text into HTML textareas. There's a learning curve, but there's a benefit to tackling that curve. For one, you get readline editing, which is _far_ more powerful than the textarea comparison, and it's customizable. For another, if you need to use your editor to manage a larger command, you have that exact option (see Ctrl-X Ctrl-E in bash/readline). That editor can be vim, or it could be your pimped out VSCode with Copilot. Bash doesn't care. When you think about it, that's a good 70% of the article's complaints resolved. Trouble navigating through lines of command input? Learn your readline keybindings, or just pop it open in your editor of choice, which also grants you syntax highlighting and whatever else. The other 30% of what article proposes are pretty decent ideas. Why _isn't_ there a way to hover over a command and see a snippet from its manual page, or to hover over a command-line flag or option, and see the data from the manual page? We have bash-completion which can provide us command-specific completion, what about docs? Many new features can be added to the current architecture. For example, OSC 52 allows terminal apps to send data to the clipboard so long as the terminal emulator supports it. I don't see why similar extensions couldn't enable applications to annotate text with documentation, etc. But that doesn't require the terminal to take over all the line editing: it's just incremental improvement to the current system. And that's where I think this article and approach are wrong. Maybe it works with the user's shell, but what about Python? GDB? Or the myriad other command line tools I use on a daily basis? As it is now, my terminal is responsible for being the best "terminal emulator" possible. It handles input, draws to my screen, and does it fast. It doesn't need to concern itself with supporting GDB: it is a terminal, and that's that. I'd rather not see these layers get smooshed. Let's focus on improving the current system so that GDB, readline, and the other pieces of the puzzle can incrementally improve the situation.

CharlesW 4y ago

What do heavier terminal users think of Warp's philosophy vs. Fig's (which I've found useful as a relatively-light terminal user)? https://fig.io/ https://fig.io/

brendanfalk 4y ago
Founder of Fig here. For context, Fig integrates with your existing terminal and shell. A few things we've found: 1. Developers are understandably opinionated about their terminal/shell setup. It's a matter of personal productivity. 2. We have noticed a general trend of more terminal use happening in IDE, not a standalone terminal. 3. Most terminal "collaboration" happens asynchronously not synchronously (e.g. shared scripts, CLIs, secrets etc as opposed to live terminal sharing) 4. Most of the collaboration happens at the shell level not the terminal level Given the above, we made the conscious conscious decision not to build our own terminal. Happy to elaborate more
- jasonjmcghee 4y ago
  > We have noticed a general trend of more terminal use happening in IDE, not a standalone terminal. This. I barely use terminal outside of Jetbrains, and heard similar things from other devs. And people who live in vim/emacs (I used to live in vim)- I would be surprised if they'd pickup something that might interfere with their setup, like tmux or special plugins etc. (forcing login stuff aside- assuming that'll be removed at some point) But maybe warp folks will find a way to play nice with everything, or be simply too useful to not use.

einherjae 4y ago

A lot of the complaints here can be solved by knowing that C-x e will drop you from bash into emacs to edit your current line, which then gives you any bells and whistles you’ve configured in emacs. Bonus is that this is generally available and doesn’t require a newfangled set of tools.

niemandhier 4y ago
15 years and I never heard of that! Cool featue.

beej71 4y ago

At the simplest level, this reminds me of input in C64 BASIC. You could hit RETURN anywhere on on any line and that line would get parsed as if you'd just types it in. You could cursor around, edit previously-entered lines, and so on. It was pretty neat.

kelseyfrog 4y ago

Seventy-five to one hundred percent of the author's complaints are addressed by the `fc` command and I'm surprised it hasn't been mentioned yet. Fc opens $EDITOR and upon exiting executes the saved contents. It's great for editing a complex command, but perhaps a tad obscure.

Arnavion 4y ago
Also bash supports Ctrl-X + Ctrl-E to open $EDITOR to edit the current prompt.
- quesera 4y ago
  In vi mode (i.e. after "set -o vi") in bash or zsh, you can open $EDITOR on the current prompt contents with: Esc, then v
davesmylie 4y ago
certainly pretty obscure. I'd been mucking around in shells for 20+ years before I found it. Now it's part of my core set of commands used constantly.
frankjr 4y ago
If using iTerm2, you can also press Shift+Cmd+. and it will open a small window/prompt where you can type your command while still interacting with the terminal.
deleted 4y ago
[deleted]
bitwize 4y ago
M-x shell in Emacs also covers most of the complaints. Galaxy brain: M-x eshell. Use regular Emacs commands from the shell! Define functions in Emacs Lisp, use them as shell commands!

steve1977 4y ago

set -o emacs?

aap_ 4y ago

On plan 9 you can easily edit any text in a window. Seems like a sensible idea.

bitwize 4y ago

$27 million in A round funding for a terminal emulator, folks. And it's written in Rust! For Macs only! All it needs is to detect and respond to the state of your gut bacteria and it'd be truly peak Hackernews. Good thing they got that funding a few months ago instead of now, when there's far less VC money sloshing around and the Juicero of the command line looks like a far less enticing proposition.

motbus3 4y ago

learn vi set -o vi You are free

ed25519FUUU 4y ago

What I don’t like is the non-ergonomic way that text scrolls. If three lines appear then the cursor is moved down three lines. I’m always craning my neck to try and find where the input cursor is just to reset it constantly to the “top” of the screen. I’d love it if I could just “glue” it to the bottom or top so output doesn’t change its location constantly.

kevin_thibedeau 4y ago
You can use a VT100 escape to force the prompt to the bottom by moving the cursor to line 999 col 0: \[\033[999;0f\]

biftek 4y ago

A lot of those complaints are non issues with the default terminal in MacOS. Option + mouse click moves the cursor to where ever, control+a|e move to the beginning or end of the line, option+arrow jumps words, and the arrows navigate up and down lines just fine... What am I missing?

wmf 4y ago
You're missing the fact that those shortcuts are not discoverable.
- quesera 4y ago
  An oddball custom Terminal is not discoverable either. There's no substitute for learning the tools. If you ever find yourself thinking "weird that there's no way to X", in a shell or editor, you're probably wrong.
- biftek 4y ago
  And this app is more discoverable? Those shortcuts also work in any text field in MacOS, they aren't proprietary to just a terminal.
- shric 4y ago
  Almost nothing in a shell is discoverable. Are these discoverable? ls, cat, $?, $@, <, >, >>, $(cmd), ${foo}, $((2+2)) If you can take the time to learn these (if not, why are you using a terminal?), then you can learn some shortcuts without them being "discoverable".

otikik 4y ago

I am probably not going to try this, but I am glad it exists.

AndriyKunitsyn 4y ago

The developers seem to be proud that their shell is “Rust-based”, they write it several times on the main page. But why would I care what a closed-source application is made with? Sorry if it’s blunt, but I just don’t get it.

dack 4y ago
I think it's signaling that it's probably modern, fast, and that the authors care about correctness. I think the customer has to have bought-in to the Rust hype for that to work, but since it's a developer tool, I can see how it might attract some.

MrWiffles 4y ago

I like the idea of Warp, but I just can't get past the whole "login required to use a terminal" thing. If you force a login to use your closed-source app, beta or not, I'm sorry, but I can't take any commitment to privacy you make seriously whatsoever. No matter how well-intentioned you may be. That well's been poisoned beyond redemption by far worse people than you and there's just no going back. Now if that login required barrier was removed, I'd at least be willing to give it a try. May not switch, but I'd be willing to give it a chance. But as it stands? Hard pass.

shric 4y ago
It also doesn't support/play nice with[1] tmux, which was a hard deal breaker for me. [1] https://github.com/warpdotdev/Warp/discussions/501 https://github.com/warpdotdev/Warp/discussions/501
Brian_K_White 4y ago
"No matter how well-intentioned you may be." ... and they should already know all that, and there is really no believable excuse for not knowing all that already, and I don't for a second believe they don't. So, really there is not even any doubt to give any benefit of the doubt like "even if you're well intentioned". Passed that already.

qbit42 4y ago

As a casual terminal user, I have found Warp to be a nice improvement over standard terminals. Although most of the issues raised in this article can be addressed with various shortcuts, it is nice to not have to remember these when I only pull up the terminal a couple times a week.

golang-gopher 4y ago
Didnt read their article. I have used warp to try it out like an idiot and realized that many of the things people have mentioned here were just things I did not know. Such as ALT + CLICK to bring my carot where I need it and CTRL+X and CTRL+E to use vim to edit more advanced stuff. I always use CTRL+A and CTRL+E on any shell to jump to front or back but I think I have enough information from this hackernews thread to uninstall warp.

nathias 4y ago

your problem with terminal is that you don't grok vi

ksherlock 4y ago

Let me mention MPW - The Macintosh Programmer's Workshop for classic MacOS. The shell was a text editor, just like the text editor for editing code. When you hit enter (or command-return) it evaluated the current line or selection. Command results were included in the document. (This was strictly a dumb terminal so there were no vt100 escape codes or such to mess up the display) If you were confused about the command arguments you could run commando (or use … as an argument) to bring up a GUI to select the flags. The Eddie text editor for BeOS and now MacOS X/XI/XII/XIII has a similar text-editor/shell hybrid. http://www.el34.com http://www.el34.com

robterrell 4y ago
Also -- BBEdit's "Shell Worksheet" is the MPW Workshop for today. I use it for so much every day. No commando, though, that was so great.

shric 4y ago

Dark pattern #1: Allowing the user to download the app and only then requiring the user to login/signup. This is because you know very well almost nobody will bother to try your terminal if you make it clear you require a login up front. But if they've gone to the trouble of downloading it, dragging it to Applications and running it, then maybe they'll go all the way. Dark pattern #2: On sign-up, you "agree to our terms of service" but then you have the gall to say, on unsubscribe: "you are currently subscribed to our opt-in messaging. Do you want to remove yourself from opt-in messaging?" Agreeing to a 17 page terms of service document might be technically "opting in" to messaging (spam), but it sure isn't in spirit. Opting in is when you click on a, previously unchecked, check box that has "I'd like to receive marketing from you". I'm sure there's plenty more but I uninstalled it already.

alexruf 4y ago
Agree. When I stared reading the article I was exited at first. I generally agree that terminals have a lot of legacy issues from the past and could definitely use some innovation. But I don’t see the point why a terminal should require internet-connection at all. There is absolutely no reason any of the features Warp mentions, couldn’t be implemented in a way to work completely offline. Good luck, but I don’t think any people using terminals as their daily drivers will ever use a product like this.
quesera 4y ago
I'm going to go straight to "Any terminal or shell which initiates network connections as part of its core execution model, is a huge no from me". Think about all the things you type into a shell, via a terminal!
- green_on_black 4y ago
  Stable Diffusion hentai plots.
- SAI_Peregrinus 4y ago
  The one exception I'd give is for actual remote terminals (e.g. old-style TTYs), which are inherently making some sort of network requests. SSH (Secure SHell) would be much less useful if it couldn't make network requests as part of its core execution model! Of course for a local terminal emulator no such requests are necessary.

sbbr 4y ago

golem> ed ? help ? ? ? quit ? exit ? bye ? hello? ? eat flaming death ? ^C ? ^C ? ^D ?

VWWHFSfQ 4y ago

Let's be honest here, nobody is using this warp terminal as long as it's closed-source and especially not when it has built-in tracking. To the warp terminal developers: I'm sure your terminal program is great, but stop posting this content-marketing stuff here. It's not your audience.

origin_path 4y ago
"nobody is using this warp terminal as long as it's closed-source" Lots of developers use Terminal.app, so that clearly isn't a real problem. There's no obvious reason why developers would be willing to buy a closed source IDE, operating system or cloud services but not a terminal emulator. I think people are reacting more to the login requirement than anything else.
golang-gopher 4y ago
whats hilarious, is on their discord, they want this upvoted. I dont think they realize this is bad marketing for this article to be upvoted. " We're launching our new and improved input editor. We just posted our article on the history of the terminal input, and how we could innovate on it.. We would appreciate if you could show the post some love. "Why is the terminal input so weird?” (navigate to HN and go to the “new” page and vote / leave a comment - we aren’t linking to it here because that can trigger HN’s moderation filters)" Upvote this!!!
qrio2 4y ago
Seconded, this product is like an anti-tool.
forgotpwd16 4y ago
The program may be great, may be bad, but the article is interesting when considered in the topic of terminal input and ergonomics.

eointierney 4y ago

I'm only a relative newbie but emacs Literate programming in org-mode with babel and magit and () is Still weird but so much more than a terminal

deleted 4y ago

[deleted]

qrio2 4y ago

Bro please stop shilling your stupid terminal replacement. Nobody here wants this. Almost everybody here believes you need to get comfortable working in the STANDARD TERMINAL

Brian_K_White 4y ago

If I were able to stomach this idea at all, I would just replace my terminal with Alexa or Gooogle Assistant not this.