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.
# 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 :)
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.
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.
> 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.
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
From what I can tell, lots of people have different preferences.
Some might rather enjoy a smarter autocomplete, much like IntelliSense and products like it made the older IDEs feel like text editors.
Plugins like TabNine/Codota went a step further and attempted to make the suggestions even more relevant and context sensitive.
As long as this "AI" doesn't just randomly execute commands, but rather suggests you what options are popular (locally or online, saving you opening StackOverflow, for example) or what might be relevant from the documentation and examples (so you don't have to do too much manpage scrolling), I fail to see the harm.
Oh trust me, this terminal does have major problems executing things automatically. If any command runs in the background, the stdout seems to flush into your input editor area LOL
It has to be open-source (meaning (A)GPL, MIT, BSD, Apache, etc.) to be even considered by bigger organizations (especially in Europe). I worked with medium and large organizations and if you're fully open-source you can even get funding [to help distributing open source infrastructure software], but if you do the "shady open-core" model I can't use it at least where I work.
In English, and especially in software, "libre" is often used to differentiate two meanings of "free": you know, ye olde "free as in 'freedom'" vs "free [libre] as in 'free beer.'"
Could you separate that into "free for businesses if they only want the stuff individuals want; but you can pay for a corporate plan on top to enable extra stuff" — i.e. open-core model?
Maybe 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?
> Can you explain why free and/or open source is important to you? What sacrifices are you willing to make to maintain free and open source?
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.
This terminal could be good for people learning a new commandline tool. Can fish shell show inline the documentation for the command flags during completion?
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.
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.
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.
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
> 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.
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.
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.
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.
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?
> 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
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.
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.
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.
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.
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.
Yes thats how it works for me with bash and ksh(mksh) but with zsh esc -v does not launch $EDITOR but just puts me in visual mode inside of whatever it uses for readline.
I even tried setting editor to something other then vi(scite) and it's clear that where bash and korn lauched $EDITOR on <Esc><v> zsh does not.
My .zsh file on macOS is literally just "set -o vi"
I guess there is some kind of added magic here(are you using the oh-my-ssh macro's) that's just not applied with my deliberately minimalist .zshrc.
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?
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.
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?
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).
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-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.
> 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.
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.
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.
There is a big problem with graphical programming: it is very hard to diff graphs in a graphical way. How can you even give review comments on changes? How would an automatic merge work?
Also, the benefit of graphic representation of an algorithm is that it gives an overview that is easier to understand. But the whole graph with the real details, is just harder to understand. But the details are necessary, they make simplistic software smarter and better.
You can do all that at the text level, if it makes the tooling easier; the tooling would just be operating on a canonically-chosen textual projective representation of graphical code (think: `go fmt`, but as a FUSE mount!), rather than against canonically textual code.
Changes on the text layer would be propagated back down as changes to the persisted binary AST that the text represents.
As such, any Unix tool used to manipulate text (and thereby textual source code), e.g. diff(1) + patch(1), could be used to manipulate the persisted binary AST through the text. `sed -i` would still work, even.
But you could also have other tools, that manipulate the underlying binary AST directly; where the textual projection would be the thing to update in response.
You're right: The tooling ecosystem for text-based programming is already very mature, which is why I wouldn't want to replace it. Current programming languages are stored as text anyway (trying to replace an entire established ecosystem without any steps in between doesn't really work, see Microsoft's constant failures attempting to bundle new things).
That's why my imaginary editor would work with that format, just in a more semantic/graphical way - as an enhancement rather than a totally new way of doing things. In fact the most practical way to go about it (let's work within the current ecosystem as much as possible!) would probably be to make a VSCode extension.
I'd go exactly the other way around since every programming tool under the sun already knows how to deal with text.
Graphs as a projective UX for an underlying textual model sounds a bit more ... realistic. All those "graph programming" languages don't really seem practical for real projects precisely due to the lack of an ecosystem around them.
The problem is that there's always a valid textual projection for any graph, but there isn't always a valid graphical projection for any text.
Think like: your syntax highlighter has no idea what your code when you're in the middle of typing, because once you type an opening parenthesis without yet having typed a closing one, your code no longer has any possible valid parse.
Ideally, you shouldn't be able to modify the text in ways that don't represent an atomic graphical operation in the first place. But if you enforce that, you can't really say that the textual representation is the canonical one. It's just a storage projection.
Sounds like emacs paredit mode. I tried to learn it, but in the end I waved the white flag and went back to vimming through invalid states to achieve the next valid one.
> The fact that we still write software by hand using lines of source code in a text editor is pretty ridiculous to me.
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.
> 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.
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.
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.
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.
> 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.
>That's trivially true for any "problem" that people "don't suffer from," and it's not that interesting.
Yes, and it's called denial and compromise.
>Workaround: Remember keyboard shortcuts and use them.
Notice how that's not a "workaround": it's resigning to the problem and suffering the limitations of the system. The very opposite of a workaround, which is finding an alternative easier solution to something being hard.
This apparent distinction between finding workarounds vs working around things seems to be heavily dependent on your opinion of what is hard or easy. I guess if you want to be the oracle of which workflows are good that’s fine, seems like it would be a bit annoying on your end though.
Unless ongoing costs are essential to the thing being provided then it is, by definition, rent seeking. If you sell me a book, the fact that I continue to derive value from it for years to come might be an argument that you could get away with selling it to me as a subscription, but doing so would by definition be rent seeking unless the subscription offered additional value to me somehow, and an alternative and more palatable model for extracting additional profits in proportion to the value in receiving would be to just charge more for the purchase.
The "reciprocal contribution of productivity" provided by the Warp developers is increased functionality of the software.
You can argue that you'd rather pay once for a particular version of the software (I would), or that you don't want to pay for a terminal emulator in the first place (I don't either), or that the Warp devs could stop improving the software in the future (and they could), but "rent-seeking" is still an incorrect description of their business model, and is only used by people who have an agenda trying to slander Warp for some reason.
> "Rent seeking [...] is an economic concept that occurs when an entity seeks to gain added wealth without any reciprocal contribution of productivity."
But implicit in "reciprocal contribution of productivity" is "compared to what." After having installed a barrier across a river, productivity increases by charging a fee and lifting that barrier. In that same vein, Warp spending extra development effort to block continued use of something you've already paid for and downloaded to your machine unless you keep giving them money is textbook rent-seeking UNLESS there's some value they're adding by doing so. Admittedly I should have referenced that value rather than their costs, but in practice the two are related because organizations aren't inclined to incur costs without adding value somewhere.
> and is only used by people who have an agenda trying to slander Warp for some reason
That seems like an unnecessary ad hominem. I don't even particularly care that they are rent-seeking. I just don't want to see that term redefined so far that we have to come up with some other name to refer to the same bloody concept, and especially not for the purpose of needlessly bolstering the profits of artificial SAAS. We're all adults here, and anyone who cares is presumably capable of making a proper argument for why rent-seeking is acceptable here rather than trying to redefine the word to brush their payment model under the rug.
The problem with the whole article revolves around this paragraph:
> 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.
Yes, regardless of the motivation/the author pimping his product, fundamentally he's right about the maddening nature of command input. It's terrible.
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.
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.
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
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
184 comments
[ 3.9 ms ] story [ 282 ms ] threadautoload -U edit-command-line
zle -N edit-command-line
bindkey -M vicmd v edit-command-line
But, like, this is obviously an entirely different class of problem from TFA, which is a skill issue.
`v` is also available in vi input mode.
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.
https://www.warp.dev/privacy
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:
Some might rather enjoy a smarter autocomplete, much like IntelliSense and products like it made the older IDEs feel like text editors.
Plugins like TabNine/Codota went a step further and attempted to make the suggestions even more relevant and context sensitive.
As long as this "AI" doesn't just randomly execute commands, but rather suggests you what options are popular (locally or online, saving you opening StackOverflow, for example) or what might be relevant from the documentation and examples (so you don't have to do too much manpage scrolling), I fail to see the harm.
https://github.com/warpdotdev/Warp/issues/1796
>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.
Maybe 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?
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.
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].
[1]: https://blog.jpalardy.com/posts/fish-shell-is-awesome/
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.
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.
Absolute no from me, even if their terminal truly is better and innovative.
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...
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.
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.
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):
Invoke $EDITOR on the current command line: 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.
I even tried setting editor to something other then vi(scite) and it's clear that where bash and korn lauched $EDITOR on <Esc><v> zsh does not.
My .zsh file on macOS is literally just "set -o vi"
I guess there is some kind of added magic here(are you using the oh-my-ssh macro's) that's just not applied with my deliberately minimalist .zshrc.
My .zshrc is pretty minimal and hasn't changed in a very long time, but I did find this:
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.
[1] https://github.com/warpdotdev/Warp/issues/159
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.
It shouldn’t be opt out in the first place, it should be opt in.
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.
Changes on the text layer would be propagated back down as changes to the persisted binary AST that the text represents.
As such, any Unix tool used to manipulate text (and thereby textual source code), e.g. diff(1) + patch(1), could be used to manipulate the persisted binary AST through the text. `sed -i` would still work, even.
But you could also have other tools, that manipulate the underlying binary AST directly; where the textual projection would be the thing to update in response.
Or any homoiconic language.
That's why my imaginary editor would work with that format, just in a more semantic/graphical way - as an enhancement rather than a totally new way of doing things. In fact the most practical way to go about it (let's work within the current ecosystem as much as possible!) would probably be to make a VSCode extension.
Graphs as a projective UX for an underlying textual model sounds a bit more ... realistic. All those "graph programming" languages don't really seem practical for real projects precisely due to the lack of an ecosystem around them.
Think like: your syntax highlighter has no idea what your code when you're in the middle of typing, because once you type an opening parenthesis without yet having typed a closing one, your code no longer has any possible valid parse.
Ideally, you shouldn't be able to modify the text in ways that don't represent an atomic graphical operation in the first place. But if you enforce that, you can't really say that the textual representation is the canonical one. It's just a storage projection.
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.
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.
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.
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.
Yes, and it's called denial and compromise.
>Workaround: Remember keyboard shortcuts and use them.
Notice how that's not a "workaround": it's resigning to the problem and suffering the limitations of the system. The very opposite of a workaround, which is finding an alternative easier solution to something being hard.
[1] https://news.ycombinator.com/item?id=33632437
That's not the definition of rent-seeking.
"Rent seeking [...] is an economic concept that occurs when an entity seeks to gain added wealth without any reciprocal contribution of productivity."
https://www.investopedia.com/terms/r/rentseeking.asp
The "reciprocal contribution of productivity" provided by the Warp developers is increased functionality of the software.
You can argue that you'd rather pay once for a particular version of the software (I would), or that you don't want to pay for a terminal emulator in the first place (I don't either), or that the Warp devs could stop improving the software in the future (and they could), but "rent-seeking" is still an incorrect description of their business model, and is only used by people who have an agenda trying to slander Warp for some reason.
But implicit in "reciprocal contribution of productivity" is "compared to what." After having installed a barrier across a river, productivity increases by charging a fee and lifting that barrier. In that same vein, Warp spending extra development effort to block continued use of something you've already paid for and downloaded to your machine unless you keep giving them money is textbook rent-seeking UNLESS there's some value they're adding by doing so. Admittedly I should have referenced that value rather than their costs, but in practice the two are related because organizations aren't inclined to incur costs without adding value somewhere.
> and is only used by people who have an agenda trying to slander Warp for some reason
That seems like an unnecessary ad hominem. I don't even particularly care that they are rent-seeking. I just don't want to see that term redefined so far that we have to come up with some other name to refer to the same bloody concept, and especially not for the purpose of needlessly bolstering the profits of artificial SAAS. We're all adults here, and anyone who cares is presumably capable of making a proper argument for why rent-seeking is acceptable here rather than trying to redefine the word to brush their payment model under the rug.
> 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.
Making a login required is absolutely unnecessary, though.
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.
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.
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.
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.
Galaxy brain: M-x eshell. Use regular Emacs commands from the shell! Define functions in Emacs Lisp, use them as shell commands!