I wondered the same. Then I realized it sends out requests to googleapis, segment, and sentry. Imagine having data on every dev's terminal workflow? Ca$h.

Sounds more like a good way to get your product banned from a lot of workplaces.

A lot of workplaces don't even bother to ban grammarly, which is literally a keylogger*, this won't even be on their radar.

* I feel compelled to point out that Grammarly disagree with this definition because it doesn't send every single keystroke, just the ones in non-password text boxes.

Is grammarly not correct here?

If my plugin Passwordly, only sends the keystrokes inside password boxes, is or isn't that a key logger? It's only capturing a subset of your input, like Grammarly, so not a keylogger?

If the argument is, it's not a keylogger because it's not logging sensitive information, well I type plenty of sensitive information into non-password textboxes.

I’d say passwordly also isn’t a key logger. By your definition every text editor would be a key logger. That may be the strict definition of a key logger but the commonly accepted meaning is different. A keylogger logs all keys regardless of the app being used or general use case. Often they are malicious as well but that doesn’t have to be the case.

I doubt their compelling features will be in OSS terminals any time soon. I’ve wanted a terminal that has a decent multi line editor for years, and there’s nothing out there.

Vim supports multiline editing and I'd imagine emacs does as well. In bash/zsh, <ctrl-x ctrl-e> opens up $EDITOR so you can use whatever you're accustomed to anyhow.

Most of these features are already available if one spends a bit of time configuring their terminal/shell.

Is multiline editing popular/useful? Thus far, the only occasions I've seen it shown is when someone is demonstrating it.

I use the visual-multi plugin [0] all day in vim/neovim.

I don't like using tons of plugins but multi cursor with with selective invocation like the ctrl-d of sublime etc was the main thing I missed when moving to vim. (I use visual block mode too but it's not the same thing).

https://github.com/mg979/vim-visual-multi.git

I'd say so, I find myself using it somewhat regularly.

It's pretty easy in vim once you learn how to use visual block mode. That or using Sed to replace text in a selection or the entire file.

http://paulrougieux.github.io/vim.html#Edit_multiple_lines

They are very useful! As a long time Vim user who switched to Kakoune[0] a while back, I didn't even realize I needed a good multiline cursor from my editor before it tried Kakoune. Highly recommend it!

[0] https://kakoune.org/

If you need to pass lots of arguments to a command it's super useful. Typically I don't do this because it's quite unwieldly with a standard readline editor, but I could if multiline editing was available!

Put `set -o vi` in your .bashrc

That's all you need - you don't need a whole program that collects all of your information.

I use it not infrequently for crafting big ol bash pipelines to put into scripts, specifically via emacs’ `shell` terminal emulator.

Thank you for sharing this tip ^_^

While this can be done in zsh/bash, it takes investment to understand how to use multiline specifically. And then once you leave the terminal, the same keystroke does not do anything for you.

One of Warp is that you don't have to think twice about it because it behaves similarly to text fields everywhere else on your computer.

In the terminal, I often have the feeling that personal computing revolution from Xerox PARC & Apple Computer never happened.

This works in everything that uses libreadline to accept user input (unless the binary has specifically configured library differently iiuc), so should work in all shell-like interfaces. You can customize the shortcuts in inputrc, likewise, for all libreadline-using binaries. By default, readline tries to be emacs-like. You can ask it to be vi-like, or reconfigure lots of its shortcuts to be similar to an editor you like. To be fair, "escape to real editor" is not a thing you usually do in an editor, so that will remain special.

This stuff has been in the major shells for years, through excellent editor integration. For emacs and vi it's pretty much free. If you want to integrate with a different editor, it's totally doable.

Most of the stuff sibling comment is referring to center around the feature:

'edit-and-execute-command' in bash. There is a similar incantation for zsh.

I summon it with, 'ESC v' in both.

If I open an editor then my scrollback history isn't visible (or is in a separate window). Maybe vim and emacs offer this, but that's a big commitment just for a terminal. Warp has GUI-grade editing (mouse support, etc) with things like multiple cursors in a very nice interface.

Ctrl-z will put Vim to sleep. You can look at the history and then type `fg` to bring the Vim back to the foreground.

In emacs a shell is like a text buffer where you can simply search or move around as you would do in a text file. To get command history you'd just execute `history` and then ctrl+s (find) it, or move to it with the cursor.

So does Emacs. I kind of assume vim and neovim do too, these days.

Normally I would pull the command I need multi-line editing for back from shell history, using the search operator '!' and print predicate ':p' before invoking bash's 'edit-and-execute-command' on it. I suppose while in the editor then I might need history again, but I can't recall it being an issue.

Three words for 2 tests regarding these features:

1. discoverability

2. wide spread use.

Bash and zsh fail both tests.

I love how my previous comment is downvoted with no answer by I assume bash and zsh fanboys when these kinds of features are barely used by users, because they can't be easily found.

Use something like fish to see what real feature discoverability for a shell looks like.

And I say this as a zsh user that has waded through the mountains of obscure documentation to set it up. Don't fall into Stockholm syndrome and think that if you went through hardship, others should, too.

99% of bash/zsh discussion threads are someone going: "here is awesome feature I found" (where frequently that feature is something that should have been painfully obvious to notice) and then 100 replies: "that's so cool and useful, I never knew about it and I've been using bash/zsh for N > 5 years".

I have no idea who downvoted you or why they did so. I'm seeing your reply for the first time. From what I can see, our priorities in our tools are different. Discoverability and widespread use of particular features are not near the top of my list. I have read the bash manual. For the tools I use most, I've found it to be a good investment, that has paid me great dividends.

> a terminal that has a decent multi line editor for years

You can use ctrl-x ctrl-e in most terminals.

https://unix.stackexchange.com/questions/85391/where-is-the-...

>You can use ctrl-x ctrl-e in most terminals.

Shells, not terminals.

In Bash:

    C-x C-e

This opens $EDITOR, and when you finish editing and close it, it runs the code.

haha well "decent" is in the eye of the beholder, I'd argue that vim is not only "decent" but by far the best general purpose IDE available.

> I’ve wanted a terminal that has a decent multi line editor for years, and there’s nothing out there.

You can go the other direction.

Install neovim. Run `:terminal`. optionally run `:help Terminal-mode` first so you can figure out how to get out.

Doesn't `set -o vi` do this for you? Place it in .bashrc and you're good to go.

It's great to use this with awesomewm for windows management, and vimium for browser control. Then you can develop in vim, bash in vim, browse in vim, and switch windows with vim. You don't have to learn 10 different, unintuitive, and ridiculous hotkeys for each different program or level.

I use pretty out of the box zsh with vi-mode and it... just works for multiline editing? I can simply move down and up with j/k...

It depends how you define multiline but check out: https://github.com/jart/bestline

Multiline works out of box in fish shell. I'm not sure how terminal is relevant here.

Terminals are largely owned by graybeard maintainers that aren’t interested in innovating the Unix command line. This is not a difficult change.

> I'm not sure I'm ready to have SaaS models replace core utilities and tools locally.

This isn't something you can ever be ready for. It's so completely and obviously wrong. Just say no.

The moat would be if teams depend on it for sharing workflows. Doing "teams" right on OSS is tricky, much easier to pull off in SaaS.

Warp engineer here.

FWIW, the Warp terminal will be free for individuals. We would never charge for anything a terminal currently does. So no paywalls around SSH or anything like that. The types of features we could eventually charge for are team features.

Our bet is that the moat is going to be the team features, like:

- Sharing hard-to-remember workflows

- Wikis and READMEs that run directly in the terminal

- Session sharing for joint debugging

Our bet is their companies are willing to pay for these. BTW, even these team features will likely be free up to some level of usage and only charged in a company context.

> The types of features we could eventually charge for are team features.

You can probably maximize community acceptance if you provide clients that do not use these features as actual FOSS and only start incorporating closed-source pieces for those features. With things like client keys etc to restrict server access.

A bit like the Chrome/Chromium thing was intended initially.

> - Sharing hard-to-remember workflows

Those get codified into ansible and deployed on CI/CD pipelines. This is an anti-feature. The day that someone suggests using a terminal to manage hard-to-remember workflows is the day I start a huge crusade to fix whatever process led to introducing yet another tool.

> - Sharing hard-to-remember workflows = Make better scripts and put in CI

> - Wikis and READMEs that run directly in the terminal No thank you

> - Session sharing for joint debugging = That's more for development.. not for shell access

> Our bet is their companies are willing to pay for these. BTW, even these team features will likely be free up to some level of usage and only charged in a company context.

I actually don't want them. I migrated from many apps that do too much to apps that do one thing really well.

What would be the advantage over version controlled shell scripts?

(Not affiliated with Warp but care about this particular thing)

Shell scripts implies, well, a particular shell. If everyone is on similar OSes, maybe that works for you, but as a Windows user, "pile of bash scripts" might as well be "doesn't work for you." I use a terminal for my daily work, but don't have bash installed on my machine.

That said, I haven't tried Warp yet specifically because it's Mac-only right now. Even within that context, Warp integrates with Bash, Zsh, or Fish, which do have their own extensions to POSIX shell, but at least you can rely on Bash being installed.

That would also now force everyone to use this proprietary product instead of whatever they're familiar with.

For mac <-> linux, posix-compliant scripts mostly work in my experience but you have to account for different versions of gnu utils. For linux <-> windows, if it's small you could just write a powershell script, or use something like python on both, no?

I fail to see how these features are nice enough to force people to use a proprietary terminal that, for now, is compatible with existing bash/zsh shells.

Yes, that is true, but it does seem like that's what their strategy is. If you're using these collaboration tools at your job, you'd have to be using the product already. So that's less of a problem than it would be for say, scripts included with some sort of open source project.

My point is mostly that shell isn't cross-platform, and this is one way you could address that. But it's not a generalized solution, absolutely.

(and yeah, something like Python is better than trying to keep multiple of the same scripts in different languages, for sure. You can do it if you wanted though, if they're small and you're willing to commit to it, I'm not sure I've ever seen it really pulled off.)

>shell isn't cross-platform

basically every operating system has a posix shell by default except windows, but it has been ported there multiple times, samba existed for decades and WSL is on the rise. It may sound a little more irritating but they deserve it for still running windows :p /hj (besides you can just host an ssh server)

I mean, I could also tell you "Just download and run PowerShell, it's ported to Linux", but you also know that would make you feel like a second-class citizen, because you know it's not something as good as something that actually works on your platform in a real sense.

Nix(OS) already solves this problem.

I cannot use Nix on my platform, and I’m not changing OSes.

Which platform do you use?

Why would it be easier to port Warp to a new system compared to Bash, Python, Perl, etc.? These tools are widely used to automate workflows and are already ported to any system you would probably care to develop on.

You aren't the one porting Warp, but you are the one porting the shell script.

So programs/workflows written in Warp will be portable without much effort, in some way that an equivalent shell or python script isn't? Why do you think that?

It seems like you’re grouping a bunch of things together and saying I have opinions about them that I don’t. Let’s break them out:

workflows I would assume to be portable, yes. It is an assumption. I generally expect program configuration to be mostly cross platform by default.

I’m not sure what a program written for a particular terminal would be, so I’m not sure if I’d assume portability or not.

Shells are not ubiquitous, even if they are available across platforms technically.

Python is truly cross platform and largely ubiquitous.

Ok, maybe I misunderstand what a "workflow" is. Since we are talking about replacing shell scripts with "workflows", I assumed that they are a kind of programming facility of about similar power as shell scripts. But that may be incorrect.

> You aren't the one porting Warp, but you are the one porting the shell script.

It sounds like your are saying somthing like "Warp scripts/workflows require almost no effort to port, compared to the shell scripts they replace". I was interested to learn how this can be the case. Perhaps my interpretation was wrong.

I may also be too; like I said, I haven't used Warp yet. Just read their docs. "Workflows" are described in their docs as effectively 'aliases with better docs that integrate with a search bar', and are defined in a YAML file. They don't actually show said YAML file, so I don't know how complex they are. If they give you the full power of the underlying shell, then yeah, you're back at the exact same problem, but if it's stuff like "invoke this program with this set of arguments," which is what their examples seem like, then I'd expect it to work with any shell as long as that program is installed.

> Perhaps my interpretation was wrong.

And perhaps mine is. The docs aren't in-depth and I don't own a Mac. But really, ultimately, "are workflows more portable" isn't a question I personally am wed to; it's that "shell scripts are only portable via UNIXes and there's a much bigger world out there" that I am, and I am hoping that workflows are more portable than shell scripts. In practice, they may be, or they may not be, but since they're in a layer above the shell, it's possible that they're not shell-specific.

Thats a good question. In the end Warp programs/scripts will be written in just yet another interpreted language.

That's a great question! Version controlled shell scripts are very useful (and in fact workflows in Warp can also be version controlled) but they still have a few problems: 1) Documentation--when a repo has a lot of shell scripts, it can be very difficult to know which command to run in certain situations. Even if each shell script has documentation, there's no way to find that documentation natively from the terminal itself. 2) Searching--you can only execute commands from the terminal based on the shell script name but there's no easy way to search for a script based on _what_ it does or any other metadata.

> - Wikis and READMEs that run directly in the terminal

Nushell can open READMEs natively and can admittedly work with Wikis through a plugin.

$3.99/mo for the Pro plan let's you run as many concurrent processes as you want!