from Hacker News

Why is the terminal input so weird?

by zachlloyd on 11/16/22, 6:38 PM with 178 comments

by shric on 11/16/22, 10:38 PM
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.
by smoldesu on 11/16/22, 7:19 PM
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.
by MrWiffles on 11/16/22, 10:11 PM
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.
by lordleft on 11/16/22, 7:37 PM
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.
by ploum on 11/16/22, 7:23 PM
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-ev...
by 0xbadcafebee on 11/16/22, 7:35 PM
> 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.
by brenns10 on 11/16/22, 8:03 PM
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.
by kelseyfrog on 11/16/22, 9:29 PM
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.
by zokier on 11/16/22, 7:19 PM
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.
by AndriyKunitsyn on 11/16/22, 10:05 PM
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.
by VWWHFSfQ on 11/16/22, 10:47 PM
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.
by apetresc on 11/16/22, 7:16 PM
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.
by bitwize on 11/16/22, 9:43 PM
$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.
by biftek on 11/16/22, 9:58 PM
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?
by chungy on 11/16/22, 7:42 PM
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.
by ksherlock on 11/16/22, 10:24 PM
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
by mostlysimilar on 11/16/22, 7:24 PM
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.
by danny_warp on 11/16/22, 7:32 PM
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-tel....
by blitz_skull on 11/17/22, 3:17 PM
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.
by ed25519FUUU on 11/16/22, 9:53 PM
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.
by drcongo on 11/16/22, 7:25 PM
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?
by beej71 on 11/16/22, 8:39 PM
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.
by Brian_K_White on 11/17/22, 12:01 AM
If I were able to stomach this idea at all, I would just replace my terminal with Alexa or Gooogle Assistant not this.
by kevdoran on 11/16/22, 7:42 PM
Warp looks fantastic! It looks like it's not OSS yet but they're considering it? https://github.com/warpdotdev/Warp/blob/main/LICENSE
by einherjae on 11/16/22, 8:34 PM
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.
by qbit42 on 11/16/22, 10:12 PM
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.
by hprotagonist on 11/16/22, 7:37 PM
if $EDITOR is properly configured, C-x C-e and hey presto, all is well for complex commands.
by CharlesW on 11/16/22, 8:22 PM
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/
by vander_elst on 11/16/22, 7:31 PM
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?
by deanmen on 11/16/22, 7:51 PM
Just use `M-x shell` in emacs.
by shadeslayer_ on 11/16/22, 7:38 PM
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.
by aap_ on 11/16/22, 9:41 PM
On plan 9 you can easily edit any text in a window. Seems like a sensible idea.
by terminal_d on 11/16/22, 8:01 PM
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.
by otikik on 11/16/22, 9:56 PM
I am probably not going to try this, but I am glad it exists.
by raydev on 11/17/22, 8:19 PM
I wonder how many people upset about Warp here also use VS Code and don't bother turning telemetry off.
by eointierney on 11/16/22, 11:05 PM
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
by giantdude on 11/16/22, 10:46 PM
This is 'Hacker News'. Hackers like open source.
by nathias on 11/16/22, 10:21 PM
your problem with terminal is that you don't grok vi
by qrio2 on 11/16/22, 11:43 PM
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
by thefilmore on 11/16/22, 8:00 PM
Because you haven't `set -o vi`.
by sbbr on 11/16/22, 10:41 PM
golem> ed
? help ? ? ? quit ? exit ? bye ? hello? ? eat flaming death ? ^C ? ^C ? ^D ?
by gtm1260 on 11/16/22, 7:43 PM
This is awesome
by steve1977 on 11/16/22, 9:36 PM
set -o emacs?
by puffoflogic on 11/16/22, 7:28 PM
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.
by motbus3 on 11/16/22, 9:50 PM
learn vi set -o vi You are free