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

[mschrage]

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

[dang]

All: this thread has multiple pages of comments. To see the rest, click More at the bottom of the page, or here:

https://news.ycombinator.com/item?id=27277819&p=2

(Sorry for the interruption. Comments like this will go away when we turn off pagination.)

[nathancahill]

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)

[mschrage]

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.

[stackbeard]

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
`

[oddmiral]

ble.sh[0] is also good autocompletion and syntax highlighting solution for bash.

[0]: https://github.com/akinomyoga/ble.sh

[shadeslayer_]

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

[mschrage]

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

[12ian34]

Nice website, but I wouldn't switch to this from Fish/Zsh on account of:

1. Cannot identify any killer features above what I already have with forever free tools with much larger support communities.

2. Less trust in you as a YC startup. What if you fail? What if you sell out?

3. Requirement of email.

4. Telemetry and privacy concerns raised by others.

5. Not available for Linux, and I get the feeling that Linux would forever be an afterthought since you released for Mac first (presumably, this was driven by financial reasons).

[zumu]

> 2. Less trust in you as a YC startup. What if you fail? What if you sell out?

> 3. Requirement of email.

> 4. Telemetry and privacy concerns raised by others.

Dovetailing on these...

Like why is a CLI tool VC backed? Is the business model just selling our data? Is the VC backing for another product and the CLI tool is just a PR thing?

[stakkur]

You summarized my exact feelings about it, especially #1, 4, and 5. I get the feeling that the team hasn't done their homework on potential users and existing solutions.

[simias]

I agree with all of your points and I probably would never use this product. That being said regarding Linux support, given the fact that Fig effectively needs to hook into your terminal emulator and your shell to drive a custom overlay, it seems like it would be a huge headache to add support for Linux given how heterogeneous the terminal setups can be on the platform. Imagine having to support urxvt running zsh on X11 and the gnome terminal running bash on Wayland or xterm running tcsh or...

I think on Linux it would make more sense to directly modify one of the many existing terminal emulators to add this functionality or you'll have to severely limit the supported configurations.

[verdverm]

Point 2 is how I feel these days. It's hard to trust any low-level (installable) dev tools supported by VCs. Personally, that hard to trust is also moving up the stack, maybe more so because of the increased attacks on the software supply chain vendors (i.e. CodeCov, SolarWinds)

[nerdponx]

#1 I do not agree with. This is a great idea for a tool, and I am willing to pay for it. This is an extension to my terminal and a useful adjunct to my shell, not a replacement for either.

#5, maybe but that's fine. Lots of things are Mac-only or Linux-only. It's a proof of concept. Moreover they appear to be working on some kind of standard specification for completion meta-data, which other tools can start to adopt and use if it turns out to be a useful spec.

#2-4, it's open source (at least it looks like it's open source from the website). If the startup sells out, the project can be forked.

[rkeene2]

Point #4 is particularly salient since it seems like telemetry information for a CLI-based tool which monitors the user's keystrokes doesn't provide the user any advantages.

[mschrage]

We started with macOS because I have a background in Swift development. Linux is definitely not an after thought to us!

As for the telemetry concerns, I totally get that. We've tried to strike a balance and it seems like we've got it wrong. This will be fixed in the next update.

[zzyzxd]

> 1. Cannot identify any killer features above what I already have with forever free tools with much larger support communities.

It does have the features I want, although not enough to convince me to switch right now. cli can be painful if you are working on commands you are not familiar with. IMHO, this is a better interface than the ones in Fish/Zsh, that provides richer information regarding command choices, hence can be a huge improvement for discoverability.

Imagine that you are not familiar with AWS EC2 and want to spin up an instance to play with. If you do that via awscli, first you need to run a bunch of `--help` commands to find the correct subcommands(`aws ec2`, and then `aws ec2 run-instances`), after that, there are 40+ flags for `run-instances`, some are mandatory, some are optional. If you do that from the web console, there's a very friendly wizard with several pages breaking down by networking, storage, OS...etc, intuitive and easy to understand.

[colonelpopcorn]

You can stop at #1. Why do I need this when oh-my-zsh exists?

[avinassh]

Can you suggest some tools which auto suggest like Fig and work with zsh? The built in auto complete in zsh works nicely, but how do I get the drop down of all options?

[smsm42]

4 is a killer for me. I like the idea, I'd probably like the tool, but no way I'm installing a thing that sends out everything (or substantial part of) I type into CLI to the external server. Too much risk. I am ready to trust they mean well and make the maximum effort to make it work securely, but it's just not something I'd ever feel comfortable with.

[cholojuanito]

>5. Not available for Linux, and I get the feeling that Linux would forever be an afterthought since you released for Mac first (presumably, this was driven by financial reasons).

I am amazed that a CLI tool isn't made for Linux

[pclark]

#2 is really quite absurd - especially here of all places - how do you decide if a product or service will never "sell out"?

[gtf21]

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?

[dangom]

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.

[brendanfalk]

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).

[vrtcn]

Highly dubious... asking for access to control the computer, asking for email, communicating with their servers. I don't care how much time this would save me, it absolutely isn't worth the risk.

[djrogers]

This looks nice, but requiring an email during setup, with no explanation or discernible reason - and demanding a work email at that - seems very creepy.

This decision alone removes my trust in your product and your company, sorry.

[woodruffw]

I noticed that you're using macOS's Accessibility API to provide your autocompletions. That's a clever use, and it sidesteps a huge source of pain when trying to make terminals smarter (i.e., dealing with the TTY/PTY layers, terminal capabilities, &c).

My question, since you mentioned that Linux support is "not an afterthought": how do you intend to support Linux? Your architecture on macOS is essentially a (benign) keylogger that I'm liable to trust because of Apple's strong isolation of concerns/entitlements; no such isolation is (consistently) available across Linux distributions. I suspect that most developers on Linux won't want your proprietary client running as a logger over X11 or Wayland.

[lasfter]

I detest that it has become normalized to grant tech companies access to personal data with only limp promises that it won't be misused.

If you give Fig permissions to look at what you are typing into the terminal, you should be prepared for them to look at what you are typing into the terminal and use it how it best serves them. They're asking for more permissions than that of course.

Imagine giving FedEx a copy of your house keys "just so they can guarantee safe delivery" without any legal recourse if the delivery people decided to help themselves to the contents of your fridge, or make photocopies of your documents.

[albertzeyer]

There are many related attempts to make the terminal more modern, by including some HTML in it, improved auto-completion, and many other ideas.

For example:

- TermKit (https://github.com/unconed/TermKit, https://news.ycombinator.com/item?id=2559734)

- GateOne (https://github.com/liftoff/GateOne)

- DomTerm (https://domterm.org/)

- Extraterm (https://extraterm.org/)

- GraphTerm (https://github.com/mitotic/graphterm)

- HTerm (https://news.ycombinator.com/item?id=7539648)

- Terminology (https://www.enlightenment.org/about-terminology)

I wonder about the state of these, or in general about terminal emulators.

I really miss some extended features, like foldable text (https://gitlab.freedesktop.org/terminal-wg/specifications/-/...) or even just standardized image support (https://gitlab.freedesktop.org/terminal-wg/specifications/-/...).

And maybe this could be further extended to also directly support sth like this autocomplete support.

It becomes tricky when you think about how this works well together with tmux, SSH, Mosh, etc.

[mschrage]

These are all such cool projects. We took some early inspiration from TermKit! I think the tricky thing is that you need to switch terminal emulators in order to use the new features.

We've tried to make everything as backwards compatible as possible. Our goal is for Fig to integrate seamlessly with your existing tools and workflows.

[crazypython]

This is misleading. Fig's completions data files are open-source, but the completion engine that runs the completions is completely proprietary.

That means you contribute free ("open source") completions to them, but the scope and type of the completions is limited by their proprietary engine.

--- YC has pinned the founder comment and made it an impossible to reply to the top-level comment.

They say the most effective forms of advertising are the ones we don't realize are ads. Well, this is an ad.

[vhanda]

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)

[brendanfalk]

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

[hnarn]

> Please excuse my paranoia.

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

[bredren]

If this is a real concern, I recommend Little Snitch or similar. Many apps do not offer any way to turn off various pings.

[throwawayboise]

Judging from the other comments I'm in the minority here, but I use the command line precisely to avoid this kind of pop-up distracting stuff. I'm one of those programmers who disables intellisense, etc. as much as I can.

[WORMS_EAT_WORMS]

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!

[jlg23]

I've been a unix user for more than 2 decades now and have seen many of projects like these. And I've dismissed all for the simple reason that they don't fix the problem at its roots: getopt et al should be instrumented to provide valid completions for all unix commands. A layer on top is destined to be out of sync with the actual implementations soon. We only get one more level of indirection, one more abstraction layer that can go wrong. I simply don't get it.

[Closi]

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.

[renewiltord]

Cool tool. I like this sort of thing. Some feedback:

* Telemetry page is scary, man. I disabled everything instantly. This "we send a ping every time you" is too much. It's not even the content. It's the fact that I fear some sort of limp CLI because of slow Internet. I have to admit I am glad you made a clear telemetry page but I am sad you chose to put all that stuff into it. I'm generally a high-telemetry guy so I would have given you a fucking shit ton of data (I even install popcon on Debian) but I don't want my shit to slow down noticeably as a result.

* Sign in at the end of the setup process. Clever. I've already committed work into it. Used car salesman tactic, but fine, I get it.

* Your tutorial page didn't autocomplete `fig` CLI commands. When I typed `fig se` and hit Tab I got `fig settings.json`. Not inspiring.

* Prompt for iTerm 2 very good.

* Tool itself is pretty good. UI quite snazzy. Some unpredictability in whether I can just go to a folder vs. it tab-completing to a subfolder. Still, so far I like it. I'll respond tomorrow.

[vptr]

By looking at [2] from the authors post. This just defeats what shell is made for. Shell is all about scripting not clicking mouse around and writing some custom commands.

I really don't understand who would use this. Maybe i'm too oldschool and grew up with shell so i'm used to the complexity and power it provides.

Would probably never even try such a tool.

[d--b]

I mean no offense this is really appealing to me, but how are you going to monetize this?

[mschrage]

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.

[pandemic_region]

> We plan to monetize by supporting autocomplete for companies' custom scripts and internal CLI tools.

[klinskyc]

Presumably charge companies per-seat for their engineers to use it?