Launch HN: Fig (YC S20) – Autocomplete for the Terminal (fig.io)
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
390 comments
[ 3.1 ms ] story [ 282 ms ] threadI 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.
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).
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:
(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)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.
For python argparse, there is argcomplete in the same vein
Then it just comes down to the Fig popover UX.
[0] https://github.com/withfig/oclif-plugin
(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)
[0]: https://github.com/akinomyoga/ble.sh
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.
1 - https://xon.sh
2 - https://i.imgur.com/p8TFdKv.png
(You can use your personal email, if you prefer!)
Alacritty: https://github.com/withfig/fig/issues/28 Kitty: https://github.com/withfig/fig/issues/26 More: https://github.com/withfig/fig/issues?q=is%3Aissue+is%3Aopen...
If you know any win32 devs, let me know :)
https://sw.kovidgoyal.net/kitty/
Kitty has a terminal graphics protocol
https://sw.kovidgoyal.net/kitty/graphics-protocol.html
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)
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
> 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.
It was also more than a little controversial.
Expecting your terminal to have a default setting to not call home is not paranoia: it's absolute common sense.
You can see our full privacy policy here: https://fig.io/privacy
You will see my login name, the structure of my folders and my intent to take over the world. Kinda sensitive, it seems.
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`
Running `defaults write com.mschrage.fig sidebar hidden` should make it disappear.
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).
This image may help clarify: https://fig.io/images/slideshow/screenshots/ssh.png
That said, it's pretty attractive because it's much harder to make a case to install fish on remote servers.
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.
Agree RE bash but at some point doesn't one just use the tool with the featureset one wants?
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!
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.
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 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.
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.
We then map then look for a corresponding completion spec to generate suggestions!
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.
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?
Does the VSCode implementation run on Linux?
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 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?
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...
Happy to be one of the first 1000 devs that you personally get to know.
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
We were getting rate limited by Github when downloading the newest completion specs earlier - that might have been the issue as well!
I’m having quite some trouble understanding why I would add a tool that potentially sends all my terminal to the web…
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!
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
I swapped my builds and it's working perfectly, thank you and good luck to you and the team.
If it's different, want to create an issue for us and we'll get to it this week? https://github.com/withfig/fig
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