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.
Think about all the things you type into a shell, via a terminal!
Of course for a local terminal emulator no such requests are necessary.
So it doesn't solve the problem then. The problem is that terminal input doesn't respect[1] the other conventions we're used to. I've used iTerm for... 5 years now? and had no idea option+click was a thing. I even had to enable a non default keybinding preset (something named like "natural keybindings something") to get the basic option+left/right arrows to move the cursor word by word.
I like iTerm, but a more natural prompt option would sure be appreciated. Warp may not be the solution because of dark patterns but there are no reasons to keep terminal input stuck in the past, they're onto something. Just the ability to consider inputs and outputs as more than just text is great: I can actually copy a whole output without having to select the characters and being careful not to go to far/not far enough, or getting stuck because the output was bigger than my configured scrollback. You could also get true output separation between stderr and stdout.
[1]: yes I know it's technically the other way around, no I don't care
“Warp.app” is an app downloaded from the Internet. Are you sure you want to open it?
"Rent seeking [...] is an economic concept that occurs when an entity seeks to gain added wealth without any reciprocal contribution of productivity."
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.
Please note that our business model is not about collecting and monetizing any of your personal data.
>The app is 100% free for any and all individuals.
I assume the usage of the upper-case F in "Free" indicated libre, not gratis. Your comment is about the latter.
Doesn't matter, any kind of connection to the mothership or telemetry is a no-no...
You could have corporate edition, with telemetry and everything or a personal one.
But no self-respecting dev is gonna use a terminal calling home for personal use...
There is no such thing as a good and well-intentioned and safe-trust-us way to do it. The fundamental concept is offensive from the outset.
There is no nice and honest and integrity way to do a fundamentally bad thing.
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
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 toolsMaybe with a proprietary binary release that includes the corporate features, and an open-CI/CD binary release that doesn't, ala the Chrome/Chromium split?
Why should you have to make sacrifices for it? If I were demanding an open-source solution where one didn't exist, that would be one thing, but here I (and presumably also the parent) intend just to keep using an open-source solution that works perfectly well for me.
Tools with better DX (developer experience) are a market that's been tapped into heavily in the past few years, personally I'm not surprised there's a pricing page. Would I pay for something like this? Probably never; I don't feel like I need to optimize my terminal workflow even if I have to reach for the manpage of a command from time to time.
Yes, it can. It's not the full docs of course, but tab completion for flags often comes with a one liner about what it does from the docs [1].
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.
... 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.
Warp's pricing model is a whole other issue though.
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.
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.
> In turn this means that anyone who has wanted to improve the terminal editing experience needs to do it at the shell level – and this is what some shells like fish try to do (as well how shell plugins like OhMyZsh work). They can only do so much though, and, crucially, they can’t make terminal input work overall in a less “weird” way.
They provide no justification on why that would be true, and indeed I believe almost all of their fancy features could be built in terminal also. Their explanation on terminal input is ridiculously naive, largely ignoring how control characters can be used to do a lot of things.
Tab completion is a half-designed solution, and not exactly portable across shells.
Terminals need to stop pretending they are dumb 8" CRTs from the 1970s. Virtually all interactive terminal input is through GUI applications at some point, and if it's not, it's not by choice.
And performing stdin input in scripts for programs that need it? Don't get me started, and don't say "expect" with a straight face. The fact that scripting languages have no provisions after 40-50 years is nuts.
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...
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.
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.
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.
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.
Well, it wasn't hard to beat punch cards in terms of convenience (BTW did you use them once?), but apparently it's very difficult to beat text editors because they've survived for 50+ years despite the fact the mouse was available in the 80s and that people have been saying that sort of thing once in a while for at least 3 decades.
Agreed. This makes some changes that could be simple unnecessarily hard. Formatting shouldn't even be a thing. FWIW though, having an auto-formatter on save has solved a big chunk of that pain for me.
Also git blame becomes kinda pointless.
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.
Galaxy brain: M-x eshell. Use regular Emacs commands from the shell! Define functions in Emacs Lisp, use them as shell commands!
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.
thefuck (https://github.com/nvbn/thefuck#how-it-works) does exactly that...
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.
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.
" 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!!!
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.
`v` is also available in vi input mode.
But, like, this is obviously an entirely different class of problem from TFA, which is a skill issue.
# edit long commands
autoload -U edit-command-line
bindkey -M vicmd v edit-command-line
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.
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?
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".
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.
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.
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.
Absolute no from me, even if their terminal truly is better and innovative.
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....
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.
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.
\[\033[999;0f\]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?
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
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/64e32421a43d3b8194d0409ce...
[1]: https://github.com/prompt-toolkit/python-prompt-toolkit/blob...
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 if you're interested.
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
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.
Is it possible to work with vim in warp?
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.
Making a login required is absolutely unnecessary, though.
Literate programming in org-mode with babel and magit and () is
Still weird but so much more than a terminal
? help ? ? ? quit ? exit ? bye ? hello? ? eat flaming death ? ^C ? ^C ? ^D ?
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.
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.
Enable vi mode (usually in .zshrc but you can test from the command line):
set -o vi
ls -la /tmp<Esc><v>
You can use up-arrow to go through command history, reach the one you want to rerun with modifications, then press Esc, v.
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.