Launch HN: Fig (YC S20) – Autocomplete for the Terminal (fig.io)

559 points by mschrage ↗ HN
Hi HN! We’re Matt and Brendan, co-founders of Fig (https://fig.io/hn). Fig adds VSCode-style autocomplete to your existing terminal.

We built Fig because of our own struggles in the terminal: we were tired of context switching between man pages, Stack Overflow posts, and Medium tutorials anytime we got stuck. We wanted our CLI tools to be more discoverable.

The terminal is powerful, but unforgiving. It emulates the constraints of hardware (like teletype printers and video terminals) that became obsolete a generation ago. There are no built-in affordances. No hints about the 'right way' of using a tool or even finding the right tool for the job. Beginners are thrown in the deep end. And even seasoned developers can screw up their system with a few unfortunate keystrokes.

To solve this, we add a UI overlay that is linked with the interactive shell. As you type, Fig pops up subcommands, options, and contextually relevant arguments in your existing terminal. For example, you can type `npm run` and Fig will show you the scripts available in your package.json. You could also type `cd` when SSH'd into a remote machine and Fig will list the folders within your current directory on the remote machine.

We use the Accessibility API on Mac to insert text on your behalf and read what you've typed. We also integrate with the shell to determine the current process and working directory. We are built natively for macOS in swift. We built our UI using web technologies so we can ultimately go cross platform. We render it using a WKWebView (not Electron).

Fig is free for individuals and always will be. All completion specs - the templates used for generating CLI suggestions - are open source and anyone can contribute [0]. We plan to monetize by supporting autocomplete for companies' custom scripts and internal CLI tools. Ultimately, we want to bring other process documentation (like SRE runbooks or deployment workflows) closer to the environment where it's used. You can see an early iteration of Fig in this HN thread from last July. [1]

Fig is designed to be private. All processing happens locally on your device. None of your keystrokes are ever transmitted or stored by Fig.

We'd love to hear your feedback on what we’ve built! We're still in private beta (so things may break!!), but we are letting HN users skip our waitlist today and tomorrow using the link above! :)

----Edit----

We really appreciate all of this feedback! Brendan and I want to address some of the most common concerns below:

Telemetry: Fig has basic telemetry in order to help us make product decisions. We currently give the you option to opt out of all non-essential telemetry by running `fig settings app.disableTelemetry true`. This removes everything except for one daily ping. We use this ping to help us understand how many people were using Fig.

Adding this ping was a mistake. We have already removed it and will be pushing this change in our next build (v1.0.43).

Business Model: Under the hood, we've built an API layer on top of the terminal. This API lets you create visual apps. Autocomplete is the first app we've built using this API. We have many more planned for things like interactive runbooks for SREs and automating deployment workflows. You can see some early prototypes here. [2] We plan to monetize these team-based apps by charging per-seat.

Autocomplete will always be free for individuals. We will never sell your data.

[0] https://github.com/withfig/autocomplete

[1] https://news.ycombinator.com/item?id=23766980

[2] https://withfig.com/videos/old-sizzle-reel.mp4

390 comments

[ 3.1 ms ] story [ 282 ms ] thread
(comment deleted)
I mean no offense this is really appealing to me, but how are you going to monetize this?
Presumably charge companies per-seat for their engineers to use it?
Love to hear it! Autocomplete is free and always will be. Our plan is to monetize by charging for collaboration features at the team-level.
Sorry didn't see that. On a side note: I deleted the app when it asked me for my email. Good luck.
(comment deleted)
Personally I am not a huge fan of asking for an email address at the end of a installation process.

I find it disingenuous as it makes users feel as if they're being offered something "for free" only to pull a "gotcha" after I gone through a lot of steps to reach the end of the installation process.

I feel it's far more candid to place the email gathering step at the start of the process so I know "okay, these guys aren't charging money, but they do at least want an email address to use this software". From there I can base my decision on how comfortable I am with providing my email address without going through the work of downloading, installing and updating system privacy settings first.

I completely understand the need to build up a list of client email addresses and that nothing in life is free, however; I think this should be done in a more tactful way that doesn't make me feel like I am have been "cornered" into providing my contact details at the end of a lengthy installation process.

Additionally; I think it's questionable that you hide the fact that you track users behind a low-contrast drop down in the installation process, and that tracking is switched on by default. I should be able to opt out before the installation process is completed and not be required to manually opt out via an arbitrary command that is difficult to remember after the installation is complete.

Finally; @mschrage - There's no doubt that what your team has built is beautiful and really nice to use. Thank you for sharing it with this commmunity and congratulations on your launch. I wish you the best on your journey and hope you'll reconsider some of these less-than-ideal patterns in your software.

This makes sense. Thank you for the feedback! :)
Serious question: why didn't you just give a fake or temporary email address? That's what I do all the time.
They go as far as asking to validate the email with a code... That plus the fact that they do send data to their servers for some reason...
I have a real fake email address for this. It's been compromised in a bunch of leaks, my real email address has never been. I also get way less spam in my real email.
Do you consider your email to be all that private?
In the context of an app that requests accessibility access (read: everything I do on my computer, without restriction), absolutely!
But if it has that, isn't your email address almost an afterthought? I mean, if I can keylog you, who cares about your email address?
> They go as far as asking to validate the email with a code

You can receive email in temporary email inboxes :)

> That plus the fact that they do send data to their servers for some reason...

But the temporary email inbox is some random `sdsfi39324@oduhuf.fru.xy` inbox you find on the internet (not some inbox you create by your own)... so zero data about you is sent (if any).

> We plan to monetize by supporting autocomplete for companies' custom scripts and internal CLI tools.
Congrats on the launch! Exciting to see all the progress
A few months ago I switched from macOS to windows + wsl2 and don't really miss anything from my previous workflow. This is the first time I see a mac only software that makes me wish I didn't. Congratulations !
We're hoping to get onto Linux and Windows soon! We opted to focus on a fast, macOS only version first. However, we built autocomplete in web technologies (html/css/js). This means autocomplete will be able to go cross platform, along with other apps we hope to build in the future!
Very smooth, downloaded it and played around a bit.

My first thought is why not use built-in shell autocompletion functions instead of redefining them in JS?

Zsh completions are super powerful: https://github.com/zsh-users/zsh-completions/blob/master/zsh...

Typing `git a<TAB>` yields this in my terminal:

    ~ git add
    add        -- add file contents to index
    am         -- apply patches from a mailbox
    apply      -- apply patch to files and/or to index
    archimport -- import an Arch repository into git
    archive    -- create archive of files from named tree
(btw, broken link at the bottom of this page: https://fig.io/docs/getting-started - https://fig.io/concepts/dynamic-suggestions should be https://fig.io/docs/concepts/dynamic-suggestions)
This is something we definitely should add as a fallback when a Fig completion spec doesn't exist!

The reason we created our own standard is because traditional shell autocomplete doesn't always provide metadata, like descriptions, priority or icons. Also it is a little tricky to write by hand, unless you're pretty familiar with shell scripting.

Many CLI libraries provide the ability to generate auto-completion scripts. Cobra for Golang is an excellent example. It provides functions for all the major shells and is quite simple to add to any Go CLI using the library. It also supports dynamic calls for when someone wants to autocomplete on a resource known only to the running CLI.

For python argparse, there is argcomplete in the same vein

We're building out integrations with CLI libraries like cobra and oclif[0], so you can generate a Fig completion spec automatically the same way!

Then it just comes down to the Fig popover UX.

[0] https://github.com/withfig/oclif-plugin

Does Fig then need to mirror autocomplete for any command which wants to make use of the popover UX?

(one of the reasons I would not want this tool, colors and file extensions are sufficient for types, no need for icons, popups, and yet another tool)

I have this in my zshrc. Hopefully it is helpful to others:

  # tab completion
  setopt hash_list_all
  # https://stackoverflow.com/a/14900496/8514646
  bindkey '^i' expand-or-complete-prefix
  # by category
  # https://old.reddit.com/r/zsh/comments/6l797o/organizing_co mpletions_by_category/
  # https://github.com/sorinionescu/prezto/blob/master/modules/completion/init.zsh#L60
  zstyle ':completion:*:*:*:*:*' menu select
  zstyle ':completion:*:matches' group 'yes'
  zstyle ':completion:*:options' description 'yes'
  zstyle ':completion:*:options' auto-description '%d'
  zstyle ':completion:*:corrections' format ' %F{green}-- %d (errors: %e) --%f'
  zstyle ':completion:*:descriptions' format ' %F{yellow}-- %d --%f'
  zstyle ':completion:*:messages' format ' %F{purple} -- %d -- %f'
  zstyle ':completion:*:warnings' format ' %F{red}-- no matches found --%f'
  zstyle ':completion:*:default' list-prompt '%S%M matches%s'
  zstyle ':completion:*' format ' %F{yellow}-- %d --%f'
  zstyle ':completion:*' group-name ''
  zstyle ':completion:*' verbose yes
`
Absolutely stunning - I've often wondered myself about why the terminal doesn't behave like this already, it just makes sense.

My only worry would be this is obviously so great it's only a matter of time before Apple/Microsoft see the light and build something similar into their OS - however hopefully this happens via acquisition rather than what happened to Flux, Watson and Duet.

There was this rather janky IDE for Powershell, way before VSCode even existed, called Powershell ISE, that had very similarly looking autocomplete behavior in it's terminal window.
It's still around, I just used it today. I rarely use Powershell but when I do it helps (somewhat) to use this vs straight command line. I want to like Powershell but there is so much about it that just feels off as a long time bash script writer. I am admittedly a novice at Powershell though, so maybe it is just me.
Most terminals do behave like this, or am I missing something? Sure it has some nice extras like help messages and icons but those aren't that important, right? Even super niche shells like xonsh [1] has visual autocomplete [2]

1 - https://xon.sh

2 - https://i.imgur.com/p8TFdKv.png

Why does this comment not seem legit... This seems like a bot. There is no way Apple or Microsoft would pick this up.
Sign in with your work e-mail?
We ask people to sign in with their work email, so you can share private completions for scripts and internal CLI tools with teammates.

(You can use your personal email, if you prefer!)

Thanks, I installed it. Looks like neither Alacritty or Kitty are supported yet.
I need this for Linux!
We are planning on going cross platform! What distro / terminal emulator do you use?
No GP, but I'm forced to use Windows at work, so an integration into Windows Terminal would be super great. I've also seen a lot of people use Cmder, and I would personally switch to Cmder from Windows Terminal if Fig was only available on that.
Windows is also in the works! The core autocomplete logic is easy to port over - the tricking thing is building out all of the OS level integrations!

If you know any win32 devs, let me know :)

Standard stuff, ubuntu/gnome-terminal.
This seems really amazing. Please excuse my paranoia. Your privacy policy is very well written and easy to read. That's rare.

However, Is there someway I can make Fig not send any data to anyone else? From what I understand, Fig does send telemetry information, but I'd like to be made aware of it before it asks me to give it "accessibility" powers.

Also, while Fig may not send the data to anyone. Does this also cover all the auto-completion scripts? I'm worried I'll need to audit each one.

(I haven't gone past the grant accessibility powers screen)

Thanks! We do need to put in place a proper privacy policy. But we wanted to be transparent with how Fig uses your data (hence what we have currently).

You can run `fig settings app.disableTelemetry true` to disable all telemetry except for one daily ping.

You also make a good point: in our onboarding we should move our privacy information to before granting accessibility! We will make this more clear

I love your concept and wish to cheer you on, but this statement

> You can run `fig settings app.disableTelemetry true` to disable all telemetry except for one daily ping.

contains such a blatant lie (disableTelemetry does _not_ disable telemetry) that I've already lost a lot of trust, in an area I am not willing to play trust games. I hope you rethink this, soon and loudly.

So what does it do? Is it just about the daily ping?
I assume they use it to track DAUs/MAUs. Otherwise, they only have data on installs, but wouldn't have visibility into user retention.
Yes, most likely. Being VC backed means they will want to be able to show pretty growth charts every few months.
Seems like they could've avoided this entirely just by having a daily check for updates to the app itself and accepting the fuzz factor.
I hear you and I agree. This is a huge oversight on our part and we will make the disableTelemetry command turn off all telemetry. This will come out in our next build
Nice! Good call. These HN posts can bring a lot of heat but it comes with extremely valuable feedback like this. For me it's too late; I've now seen that you need to be caught in the act before you'll do the right thing -- but for folks who didn't see this you'll be much better off going forward.
This seems really harsh. It's not like the guy tried to hide from you that it would still permit one daily ping. He told you straight up.
This is just unnecessarily rude. The guy had explicitly mentioned about the daily ping and it's mentioned on the product doc as well - so please don't make him up as the big bad guy who says I CAN HAZ DATA
I can't imagine that daily ping being worth the loss of trust from having a "disable telemetry" setting that doesn't really disable all telemetry. People who care about disabling telemetry will care about the daily ping, too.
I think you should reconsider daily pinging still taking place when the user explicitly asks to disable telemetry.
Telemetry being on by default on something like this is going to be hard to pull off. Homebrew has telemetry but it's only for Homebrew commands. This would potentially be for every single command one type in a terminal. It just takes one little bug in the app and who knows what can be sent, maybe passwords and so on.
> Homebrew has telemetry but it's only for Homebrew commands.

It was also more than a little controversial.

And why I don't use the tool.
Homebrew's telemetry burned so many bridges back in the day. I had a friend who sold his week-old 15-inch MBP over that.
Disable except for once a day is not actually disabling. That's pretty whack.
Telemetry by default in terminal autocompletion is a pretty big turnoff for me, even if it can be disabled
Please make telemetry opt in, not opt out. And please honor the disableTelemetry setting by disabling the ping.
...DNT header, but for the OS
If this is a real concern, I recommend Little Snitch or similar. Many apps do not offer any way to turn off various pings.
> Please excuse my paranoia.

Expecting your terminal to have a default setting to not call home is not paranoia: it's absolute common sense.

What does "Sensitive data is never tracked" mean? I can't find any more details, and is like to know exactly what on the terminal is considered non-sensitive?
We consider most things you type in your terminal to be "sensitive". Fig only ever tracks the root command for any completion you do. For instance, if you type `git push origin master` and complete on `master`, Fig will only ever see `git`

You can see our full privacy policy here: https://fig.io/privacy

$ /home/throwawaybutwhy/miscellanea/world_domination_plan_no_1.sh --help

You will see my login name, the structure of my folders and my intent to take over the world. Kinda sensitive, it seems.

haha :) We actually send the name of the completion spec rather the initial token. In this case, it would be "dotslash".
Hey everyone - I'm Brendan, one of the other co-founders of Fig.

Our server endpoint to download all of Fig's specs just went down. We are fixing this right now. Apologies for the hiccup! Will let you know when it's back up.

*Update*

Our server is back up. If you downloaded Fig and it isn't working, please run `fig update`

Can I use the autocomplete without the side bar on the side of my terminal?
Yes! Sidebar was a legacy feature. This is disabled by default for new users. We actually just removed the toggle to turn it on/off from our menu

Running `defaults write com.mschrage.fig sidebar hidden` should make it disappear.

I don't really understand what's so different from the ZSH completions which I already have in my terminal but with no data leaving my machine?
(comment deleted)
Traditional shell completions are quite difficult to make. Many CLI tools have completions for subcommands and options, but not for arguments. Only the big CLI tools like `git` and `docker` have arguments completions (e.g. git push [remote] [branch]`.

Fig's declarative schema makes building the completions for subcommands, options and arguments very easy. This means we can support much more powerful autocomplete for many more CLIs.

Fig's standard format also makes it possible to suggest shortcuts for standard workflows (similar to aliases but more visual).

Finally, zsh and fish have good support for traditional autocomplete, but bash does not. Fig works the same across all shells (even when in an SSH session or a docker container).

What exactly do you mean by even when in SSH or docker?
As in, if you SSH into a remote machine, Fig can offer completions for that remote machine. Same thing if you are running an interactive terminal for a docker container.

This image may help clarify: https://fig.io/images/slideshow/screenshots/ssh.png

This seems like black magic, but it really does raise a lot of questions about the telemetry issue. It's one thing to potentially leak information from your own machine, but leaking data from remote servers you ssh into requires a whole 'nother level of assurity around privacy.

That said, it's pretty attractive because it's much harder to make a case to install fish on remote servers.

I assume this is done by running 'ls' in the background and not showing the execution to the user, except as autocomplete suggestions?

if I type 'sudo cp ' will it run 'sudo ls' to offer suggestions?

this...is not good. my terminal should not be executing code on my behalf on remote servers I've SSHed to.

So wouldn't a better solution be to make a nicer DSL for describing shell completions which is then translated into zsh, fish, etc. completions?

Agree RE bash but at some point doesn't one just use the tool with the featureset one wants?

That's how we think about the completion spec standard. It essentially is a type-safe DSL that describes the structure of CLI tools.

It should be pretty easy to 'compile' a Fig completion spec down to zsh, fish, or bash. This is actually something I've been meaning to write!

> Fig's standard format

How is that a standard when you just came up with it? Any other existing autocompletion format is more standard than whatever you just released.

Yep I mistyped. Meant to say standard "suggestion" format. Trying to imply that each suggestion conforms to a specific standard that we have set but that lets you customise things like the text it suggests, what is inserted, icon etc
(comment deleted)
People who can configure their shells are not their target audience. For once, if you walk into any research center or academic environment and look over the shoulders of people who have to code or use a terminal because they have no other option, you would see that the vast majority know little beyond cd and ls. I wouldn't be surprised some would pay for directory completion alone.

Can those who know what zsh mean do a better job with existing tools or custom made scripts? 100%, but that doesn't matter.

Beyond that, you can level up even further by firing up Emacs and never again needing a terminal for things that require completion.

> if you walk into any research center or academic environment

If they use their institution's infrastructure, it's managed by the dedicated system admins. No way they're going to allow this tool to be installed.

While I have exactly 0% belief in the success of Fig, and share a lot of the negative sentiment expressed in this thread, your parent post does make a point.

I spent 10 years in the kind of academic setting described. A LARGE part of the work of the people in this example do their work on ordinary self-managed laptops without a sysadmin in sight (and probably very little common language in which to even begin communicating with a sysadmin, if they even know what a sysadmin is). The amount of time that is wasted by ordinary researchers being very uncomfortable with the terminal is staggering. Although I was/am a researcher in my own right, I do feel that I had an order of magnitude greater positive impact on research by helping out the approximate dozen of other researchers around me do their terminal and programming work more efficiently/better/smoothly/reliably.

I definitely think there's huge room for improvement in this area. But I don't think something like Fig is the answer; safe and effective use of Fig seems to require enough wherewithal to ask someone (or google) how to set up bog standard autocompletion solution in the first place.

There definitely is a point. I've witnessed too many biologists who decided to get into data analysis struggle with UNIX. I think https://missing.csail.mit.edu is more of an answer. Most graduate programs just assume you'd pick it up on your own, but the majority doesn't.
You install it in your own terminal on your own computer, not on the institutions' computers. Also, for research that doesn't handle personal identifiable information (think civil engineering or astronomy), I don't think it'd be an issue to have Fig read the parts of the filesystem to which admins gave you read access anyway. Hopefully autocomplete would work over ssh.
Perhaps, but then a better option would be to contribute back to the ecosystem by creating a nice DSL to compile back to zsh etc. completions and making a nice installer on top of that. I don't see how "autocomplete in your terminal" is really a company given that the people who would pay for tools like this will probably be power users, who would (I assume) prefer the built-in tools.
Congrats on the launch! How does this work?
Thanks! Fig does a bunch of macOS specific hacks to find the cursor location, find link your tty session to a OS window id and determine your current edit buffer (the text you've typed).

We then map then look for a corresponding completion spec to generate suggestions!

This is cool!

Is there a plan to support the completion APIs over LSP so existing tools can implement support independently? For example if I could write a language client for various language servers just for the completion apis, it would go a long way.

I'm surprised it requires nodejs on the client to run - how do you lock node versions so it doesn't break on updates, or needs to run in the same dev environment as older versions? If my dev environment has node locked to an older LTS, will fig still work?

As well, linux support would be great. So would a vscode extension so it can run in the integrated terminal, but I'm not sure if that's possible.

Fig already works inside of VSCode and VSCode Insiders!

Also to clarify: we don't require node.js on the client. The completion specs are interpreted by the Fig macOS app.

re: LSP. Super cool idea, are you imagining Fig autocomplete in language-specific repls? Or something else?

Exactly that. LSP is great because its the only semi-standard API for integrating with different programming tools, and completions are one of the built in features. Snippet support too - I can't tell how many times I've needed to write a for loop in a REPL, which would be much easier with snippets in a terminal.

Does the VSCode implementation run on Linux?

Can I pay you money for this awesome product so I don't feel bad about opting out of your telemetry? What's fair? I think a lot of us would do this voluntarily. Your privacy disclosure is great--I just don't want to be the product on principle.
You shouldn't feel bad for opting out of telemetry!
We just want people using Fig and enjoying it! That's our top priority. Don't feel bad at all about opting out of telemetry :)
Fwiw, i won't be using this because i can't buy it. I don't use any dev software that's not either FOSS or purchasable. Over the years i've suffered enough at the hands of changing monetization strategies that it's just viewed as risk for me.

Even if it stays honest and never dark-patterns me, i expect at the very least the service will change in some way. Failing entirely, dark patterns, etc. My preference for simple products i can purchase gives me confidence that it will just work as long as i need it.

No criticism towards you - just giving feedback.

I get this - it’s the whole “if you aren’t the consumer you are the product” piece.

I like using companies where your relationship with them is obvious (ie I pay money and they give me services) rather than mysterious (Ie I use Google and they use my data in a way I don’t quite understand to make lots of money from me with me never paying them).

If the first monetisation strategy doesn’t pay off what comes next? Ads in the terminal? Increased telemetry to sell to companies? Sudden removing of features put behind a paywall?

(comment deleted)
Nobody should feel bad about opting out of telemetry. It is your privacy. They should feel bad for not asking for your permission and getting consent in the first place. And making it obscure. Ironic coming from a "discoverable" app. Please donate money to actual free software and standards. Not some VC coopted "open source"
I find autocomplete for commands to be, sometimes, a little dangerous. I'd at least turn it off when root or sudo....

PowerShell does a good job with autocomplete on commands and options --if you're using PowerShell of course. Fortunately, it's cross platform.

https://docs.microsoft.com/en-us/powershell/scripting/window...

For 'dangerous' commands, Fig requires you to press enter twice - once to select suggestion and insert it into the terminal and then again to execute it!
(comment deleted)
I got tripped up on your Tips for Troubleshooting page. I tried validating install at that point. But otherwise this seems great. Hope you guys plan a Windows version too.

Happy to be one of the first 1000 devs that you personally get to know.

Just tried this at university and interestingly all fig functionality is blocked when using the university's wifi, probably due to the proxies they have in place, while hot-spotting from my phone over 4g seems to work fine.

edit: after switching back to university wifi fig also worked fine, so it may be an issue with the wifi or there may be a need to refresh the network connection when trying to set everything up

Great to hear that everything is working.

We were getting rate limited by Github when downloading the newest completion specs earlier - that might have been the issue as well!

So the added benefit of Fig over completion provided by zsh/fish together with say Cobra is the “slick” ui and the (community?) sourced completion based on man pages etc without the apps themselves having to provide completion data?

I’m having quite some trouble understanding why I would add a tool that potentially sends all my terminal to the web…

Any plan to support vscode terminal?

Also, this experience really is great. Without knowing anything I was able to disable the "Menubar Icon" simply by guessing commands.

And to try for any constructive feedback, I personally don't like logo at all. It doesn't seem to make sense to me and is the reason for hiding the icon in the first place.

Feels like a window management icon like this: https://magnet.crowdcafe.com/

Great job, will follow this closely!

Glad you are liking it!

VSCode terminal should be supported out of the box. Go to ◧ > Settings and make sure the VSCode Integration is ticked. (You may also have to restart VSCode.)

re Fig's icon: haha yes we could definitely do with a new icon. Our previous icon was an emoji pear (yes a pear, not a Fig) so at least our current one is a step up from that! We take the feedback on board and will investigate some new logo designs

Ah, you're right! I am on the "VSCode Exploration" build still from being an early M1 adopter. I guess that version doesn't work -- no idea.

I swapped my builds and it's working perfectly, thank you and good luck to you and the team.

Glad to hear - is VSCode exploration the same as VSCode Insiders? If so, I believe we do support this too (However I guess the whole idea of Insiders is it is constantly being updated so maybe our integration recently broke).

If it's different, want to create an issue for us and we'll get to it this week? https://github.com/withfig/fig

I have been using zsh-autosuggestions [1] to achieve something similar, so seeing a new product that seems infinitely easier to configure and much more powerful is very.. heartening. I might not move over right this moment, but I'll be cheering you on.

PS: I read the fine print and I (and many others, I'm sure) would really, really like to pay some money for you to not send ANY telemetry data at all. Would be great if you kept this demographic in mind.

Congrats on the launch, and all the best!

[1]: https://github.com/zsh-users/zsh-autosuggestions

Thanks so much for this! We've heard the feedback on telemetry loud and clear - definitely will rework this in the future.