Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Fig (YC S20) – Autocomplete for the Terminal (fig.io)
559 points by mschrage on May 25, 2021 | hide | past | favorite | 377 comments
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




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


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
`


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

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


[deleted]


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.


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


> 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?


Just adding, from their website:

> Investors: We've raised several million dollars from amazing VCs like General Catalyst and Kleiner Perkins, and angels like Jason Warner, Adam Gross, Olivier Pomel, Scott Belsky, Will Gaybrick and a handful of other impressive dev tool founders and executives.

The fact that a CLI tool raised millions of dollars while also being basically powered by open-source contributions is also kind of a wtf moment to me, but what do I know.


WTF indeed.

There has to be some grand vision behind this, presumably large-scale data capture. At the end of the day, the terminal is is to the dev what Google is to the internet user: the point of entry where many journeys begin, with dozens or hundreds of interactions every day. And while devs are a niche market compared to Google's userbase, they are a lucrative and strategic one nonetheless.

Casting aside the environment of low-interest rates and massive inflow of investment in startups, how does a product like this otherwise raise several millions? The pitch sounds like something that a competent indie dev studio could sell on the Mac App Store...


Yes, but when you’re Googling, you’re searching for public information.

When you’re using the terminal, you’re mostly manipulating your own data, often in ways that would reveal sensitive information if your terminal history was leaked.

Any attempt to collect data from users’ terminal interactions is indistinguishable from keylogging.


They could rationalize it as only capturing the commands and not the arguments, or something. (If that's indeed the long-term plan. No clue; for all I know data collection isn't intended as the business strategy whatsoever.)


I just wanted be a fly on the wall when Fig founders were pitching to these investors on how they are gonna make money.

Can NOT this tool say to my employer - How many times I compile my code in a day ?

When I get a compilation error - how quickly it gets to compiling state again ?

Was the compilation error a trivial mistake ?

How much time is spent between each commands ?

How productive I am keying in command one after another ?

Also can NOT Fig figure out current apps Im running on my machine ?

What is the current app in foreground ?

How long I run each app ?

When I log off ?

How many times I log off ?

It is getting interesting! Can anybody help with more usecases.


Your employer's group policy controls, management agents, etc. that control access to their internal network can (and are) already telling them all of that information. They're basically rootkits that run anything they want on computers that access their network. Usually they just distribute certs, keys, etc. or remotely wipe a lost/stolen machine, but the capability is there to do anything.


I think you misunderstand how tools like this sell, the enterprise offering will be fully supported integration of tools that are enterprisey (Cisco gear, Netapp, Fortinet, Xen, VMware, Veeam) and a hosted offering so teams can collaborate on scripts and snippets á la postman.


I saw the first few commands of the video on their site and I'm like "wait Wtf a visual representation of what hitting tab-tab does already? That can't be it"

But yes that's basically it. You have _all_ of this already and all it needs is for whatever tool you have to provide the "completion" definition file. The graphical nature of this makes it _less_ useful (as others have pointed out w/ regards to no Linux support). How this would sell to enterprise I do not get.

Kudos to them for getting funding for this tho. I wish I had the guts to take something that already exists better and free and ask for someone to pay me money to try and sell it to other people instead.


That’s one theoretical way to make money, except not only do few companies do this now, but few devs would accept that.

There are other ways to support developers thru honest tooling (eg IntelliJ).


pretty dystopian


> Can NOT this tool say to my employer - How many times I compile my code in a day ?

That would be a completely useless metric.

Also, don't you have a daily build pipeline anyways?


While debugging and coding.


Wait until they learn about incremental rebuild!


It strikes me as a pretty disgusting waste of "millions of dollars" to develop a Mac-exclusive app that does the same thing that your shell does, but slower.


Eh money is trying to park itself somewhere.

Maybe the founders sold this as a way to get dev telemetry data + a subscription.


Yeah but if there's dev telemetry involved it's a no-go from me. Definitely a no-go, the terminal is sensitive.


I mean, I agree, why is a cli tool YC backed, sure. But “several million dollars” is literally nothing in the VC space.


I mean they’re trying to be JetBrains but for Bash so it makes total sense to me why it would be a many many millions of dollars effort.

I think people forget that IDEs (which is essentially what this is) are a stupid amount of work. Then you have to add the rest of the business: sales, leadership, support, hr, ops. I mean a 25 person company $200k average total comp is 5mil annual burned cash just on salary.


This is shell completion that you can already do by hitting tab twice (if a definition file exists for your tool). If not, write a definition file.


This is Kite all over again.


> The fact that a CLI tool raised millions of dollars while also being basically powered by open-source contributions is also kind of a wtf moment to me, but what do I know.

There's probably more money than people know what to do with. So they might be investing in completely crazy ideas hoping that the founders figure it out along the way.


> There's probably more money than people know what to do with.

Not really, in the bay area engineers make $150K-500K/year (closer to the $150K end for startups) and office space costs upwards of $200K-300K/year.


I mean venture capital money.


With millions of dollars you could probably just write a shell that does this sort of completion inside the terminal.


I did exactly that for free ;)


Cool! Was it a one man project, and if so then how long did it took to get it to a reasonably functional state?


It's about 6(ish) years old and went through various states of reinvention before I landed on the current design and it's been my primary shell for the last 4 years now.


Can we check it out! :D


Sure, I'd love any and all feedback: https://github.com/lmorg/murex


> Sure, I'd love any and all feedback:

Here's one: you wasted a perfect opportunity to feast on that sweet investor's money.


Just commenting to appreciate the sea snail reference


> Is the VC backing for another product and the CLI tool is just a PR thing?

Autocomplete is our first product. The bigger vision that Fig can enable an ecosystem of terminal extensions. Here are some early prototypes we built [0] and here is the discussion from when we were posted on HN last summer [1].

> Is the business model just selling our data?

We will never sell data. That just isn't the business we want to build - Brendan and I like hacking on the terminal because it's interesting and we get to solve our own problems.

We've been lucky enough to find investors, most of whom have an engineering background, who understand how important the terminal and believe there is a lot of room for improvement.

Obviously, we would like Fig to become a sustainable business. We plan to monetize in the short term by offering autocomplete for internal CLI tools and scripts. Longer term, we think that there is a lot of stuff that developers do in the browser that make more sense in the terminal. Fig's autocomplete product is powered by an API that lets anyone build graphical extensions that are connected to the terminal.

[0] https://fig.io/videos/old-sizzle-reel.mp4

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


> We will never sell data. That just isn't the business we want to build

These are just words from strangers on the internet. You're offering a free and auto-updating app. You don't give me a contract guaranteeing anything. Most terms of use/privacy policies have a clause stating it can be updated without notice and when you do have actual policies on your site I'm sure they will be similar.

At any point you can decide that actually, you do want to share my data, or share access to it through one of your products. Maybe you won't call it "selling" (the same way Zuckerberg can tell Congress that Facebook doesn't sell anyone's data).

Maybe you don't decide to share my data, but Fig gets acquired and the new management decides to. Maybe an attacker gains access to the data and shares it. Maybe an attacker compromises an update, turning all Fig instances into keyloggers, and paired with the required email addresses uses it to compromise other data.


Good points. I'll add that the "disclosure by ransomware" risk is definitely not just theoretical anymore.


No offense, but the only way I'll believe a company will "never sell data" is if it never collects any in the first place. Even if I have ultimate trust in the current founders, what happens if/when you're acquired or the investors install different management?


Great. Looking forward to the Terminal App Store and learning why my company should pay you for the arcane knowledge of where bash_completion.d scripts go. Let me guess, a lot of emoji involved?

You are aware any shop with a modicum of competence is already doing what Fig does, right? Usually on a central or bastion server? What kind of TAM did you put in the pitch deck? People who can’t read man pages or pull apart an RPM to see how, for example, git’s completions work?

You’re probably going to price shell autocompletion per seat and you expect people to not think VC has jumped the shark? What’s your exit?


> We will never sell data. That just isn't the business we want to build

What about when that is no longer your call (e.g. the VC's want returns, you sell to Facebook, etc.)? Is there anything in place to protect us then?

> We plan to monetize in the short term by offering autocomplete for internal CLI tools and scripts.

I'd love to hear more about this. Sounds like the GHE model?


Why the fuck do you need my WORK email address with 2FA verification?


My thoughts exactly, and it was removed instantly it asked for my work email.

No, No, and no. matter fact, it earned itself a forever no. thx have a crap product launch.


> We will never sell data.

You can start by allowing to download the app without asking for email.


The product looks cool at least from the video.


> Like why is a CLI tool VC backed? Is the business model just selling our data?

Agreed. Take a look at Nabu Casa, the developers of Home Assistant and Home Assistant Cloud. They are 100% self-funded by their revenue from HA Cloud and the hardware they sell.

Because of this, I don't have to worry about investors demanding a return on investment by any means necessary and potentially generating revenue from users' private data.


CLI is a relatively "pristine" environment, where a lot of people's time is spent and nothing competes for our attention (or data as was pointed out). Any business model that could plausibly exploit this environment for financial gain would be an easy sell to investors.

I don't know anything about this product's intentions, but it's easy to imagine the possibilities once you start getting permission to pop something up in someone's terminal window.


Well, it’s even easier to imagine that they will start charging money for it. If it makes life easier for developers they can easily charge 20 bucks a month for it.


> once you start getting permission to pop something up in someone's terminal window.

Canonical already does this.


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.


No, I think it's incumbent on us developers to be more willing to pay for things. We know now that free doesn't really work.


I'm willing to pay if it's on hacker friendly terms, e.g. something similar to the Sublime Text model:

* No sign in/email required

* Works offline

* No subscription

* Updates for 3 years included in price

* Perpetual license for older versions

* License per user, unlimited devices and operating systems, including home/work devices

* License is just a matter of copying a file

* No telemetry/phoning home without explicit opt-in

* No DRM/copy protection

* No root access required

* Works on Linux


Unless something external changes the incentives in the market you aren’t gonna see bits in a box return as a business model any time soon. ARR is the only metric that matters to get you funding, it’s way more expensive to support multiple versions than something evergreen, and you can’t really do per-user unlimited device licensing without a login. You can fake it with per user keys but then someone has to have a login to manage them still and your key is now essentially just a login where self-service password resets can’t be done. Why bother when companies clamor for SSO about a billion times more than they ask for anonymous user accounts?


I'm on the same boat, although I have an additional requirement that disqualifies Sublime Text: I want the software to be source-available. Not necessarily FLOSS, but I want to know that if push comes to shove I can hack the code and recompile the software.

I don't want to have to rely on the devs if I want to tweak something that's not meant to be configurable, or if I need to run the software on some unsupported configuration and it breaks.


Sublime is special. I don't think anything can come close to it.


>> it's incumbent on us developers to be more willing to pay for things.

If it is worthwhile and not freely available, I will certainly pay. There are some great IDEs and tools that fit into this category.

>> We know now that free doesn't really work.

I suppose it depends on your needs, but I find using free tools such as zsh, vim, tmux, linux, and many others very valuable to me.


Yeah this project totally completely baffled me. "Autocomplete for the Terminal". What?? Bash has had fully programmable auto-completion for over 20 years [1] -- and that's just one comparitively bare-bones shell, out of dozens that are all free forever and not spyware.

Watching their demo didn't help either. At most the behavior seems an incremental improvement over what Bash ships with in most distros, and it's not even clearly better than that (IMO worse, I prefer the trailing slash or color-coding that Bash uses to distinguish file/dir properties vs icons). Joke: Is the "perceived need" really just because macOS's default Bash distro has these features disabled?

[1] https://en.wikipedia.org/wiki/Bash_(Unix_shell)#cite_note-60


It feels like the devs are completely clueless about open source, command line, and modern shell features.

There's so many great projects for bash and zsh add-ons like fzf.


Right: Assuming good faith, this project seems completely backwards.

But if their real product is the telemetry that also ships with it, and they've identified that many newbie developers have a hard time seeing through marketing pages directed at developers (eg like "webscale" stuff from mongodb circa 2010), then it, unfortunately, makes more sense.


Virtually the entirety of my desktop stack and dev tools are OSS. Can you clarify what you mean by "does not work" here?


Free doesn't really work? What do you think about linux, git, emacs, blender, vulkan, etc?


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.


Thanks for your insight here! We are still deciding the exact implementation, but completely agree - Linux is a challenge due to the heterogeneity of distros, window managers, compositors, etc.

Our macOS approach might not work everywhere.


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)


I agree, and since it's VC backed it also feels like this is going to end up as SaaS for your terminal.

I would honestly feel less skeptical if this was a Show HN and the founders had just organically launched an app that did autocomplete and asked for some money to buy a license. I'd put that along side similar attempts like Xiki.

VC-backed changes it though, it feels different. It'll start with a subscription model and if this requires elevated privileges to run as what could essentially be a keylogger, it won't be long before the privacy promise goes away and the marketing team takes hold.


> maybe more so because of the increased attacks on the software supply chain vendors

I'm intrigued by this but not 100% sure I follow. Is the implication that VC-backed startups are more likely to suffer from a supply-chain attack, or just more general reluctance to incorporate any new tech into the stack as it increases the attack surface area?


Probably a little of both.

I'm personally reducing this surface area with clients in light of recent attacks.

Personally, something like this w.r.t. VC means that incentives will diverge and they lose touch with what it means to be a dev tool.

w.r.t. supply chain, it's probably more of a correlation (related to) that they will eventually have the large companies as enterprise customers who are the real target. Also, once making money becomes the primary driver, other important tasks are deprioritized. I've seen both the tools and their correct usage go to the wayside.

Most abstractly I think the misaligned incentives is what happens. I'm not convinced that VCs get dev tools and don't ruin them.


> Personally, something like this w.r.t. VC means that incentives will diverge and they lose touch with what it means to be a dev tool.

> Most abstractly I think the misaligned incentives is what happens. I'm not convinced that VCs get dev tools and don't ruin them.

I'd love to hear a little more about your thoughts here. We've committed to making autocomplete free for individuals. In your opinion, what else can dev tool companies like ours do to make you feel more comfortable?


To start with, remove network related code. There is no reason for a autocomplete language to need to fetch a file or send telemetry. A telemetry setting is insufficient


Have there been any attacks that are able to exploit iTerm shell integrations or similar tooling?


ITerm has had security issues, yes, but that is besides the point.

With this product, are their collaboration features secure? Are their servers which support that secure? You are installing a tool which phones home on each command

Why do I even want a shared terminal?


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


I have found "it's open source" to be a real-life meaningless response to "I prefer tools that I am likely able to have a significant amount of autonomous control over in the future."

The software market has very effectively figured out how to make things "open source" in name only (offhand, Canvas is the one that's killing me these days), and unfortunately now all such claims must be taken with a huge grain of salt.


#1 That's fair. Each to their own. For me I wouldn't be willing to pay even £1 a year for it.

#2-4 Firstly, just because it can be forked is not to say that it will. It's not easy to maintain a whole project in your spare time. Also, this may be a moot point since the completion engine is supposedly proprietary (as per another commenter).


#5 is crucial, I highly value cross platform comparability. The existing differences are annoying enough as it is


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.


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.


The correct balance is 0% of terminal activity is sent with telemetry, unless the user explicitly and specifically authorizes it.


Just to clarify, the text you type into the terminal NEVER leaves your device. Fig does not store or collect this information.

We send an event when you insert something using Fig's autocomplete, so we can get a sense for how frequently people use the app. We also send which completion spec (eg. git, npm or cd) was used to generate the suggestions to know which commands to prioritize.


>We send an event when you insert something using Fig's autocomplete, so we can get a sense for how frequently people use the app

And this is why you're never going to get people to use it. I get that you want to know what is being used, but really -- this is a terminal. You can't have any kind of telemetry for a terminal.

If you had a very big notice when you install, asking for permission to send which commands get autocompleted, you'd have likely been in a better position. Debian does something like this on install -- asking permission to track what packages you've installed. But it very clearly optional. And their level of knowledge is just that a package was installed, not necessarily how frequently it it used. Anything approaching telemetry within a terminal is just a bad idea.

And I fail to see how you couldn't also get the same data from surveys, features requests, issue tracking, etc... It wouldn't be the same quality, but this is really really bad. And because you started out with this major faux pas, you're going to have a major problem with trust going forward.


+1 for this. I don't wanna be rude, but dataops isn't a joke: I'm not going to put my security into the hands of someone who already made egregious security oversights an integral part of their product.


A distinction without difference, in my opinion. And it doesn't change the fact that anything other than 0% telemetry without full, complete disclosure and permission from the user is not good.


> generate the suggestions to know which commands to prioritize

What does 'prioritize' mean in this context? Other completion tools (like fasd) write command history to a local dotfile so they can build up knowledge of 'frecency'. This makes sense, it's no different to your ~/.bash_history file really. I wouldn't trust any single tool that tried to build a parallel history through an analytics integration.

Fig claims that it 'loads up once then remains entirely local', though, and it's adorned with an icon that suggests it remains offline.

What you're saying here seems to contradict that. If the tool is entirely local/offline, how is it phoning home with the commands you type? And does it send along the arguments you pass to the command if you happened to complete them?


So wait a second, the text I type into the terminal never leaves my device, but the commands I invoke do? What's the difference?


Yeah just don't accidentally paste your password into a terminal and press Enter.


I don't know if that's a fair reading of the functionality. It seems likely your mistakenly pasted password will generate an autocomplete and the (mis-)matched "spec" command will be sent as the telemetry, e.g., pasting "gi)#(RCS23!_)(U" into your terminal might result in "git" telemetry, not the password itself.

It's one of those things that is just trivial to introduce breaking changes to, though, intentionally or otherwise. And as-is the functionality does share what amounts to the terminal activity in normal cases.


Just add "0.0.0.0 fig.io" (or whatever it is, wireshark it to find out) to your /etc/hosts


Doesn’t it auto update? That’s a cat and mouse game I wouldn’t want to play.


> I have a background in Swift development.

Then why on earth did you go out of the way to implement this in JavaScript instead?


The current implementation of Fig is a native macOS app (Swift/ObjC) that exposes an API to access terminal specific information - edit buffer, working directory, current process, etc. On every platform we support, we'll implement this natively.

As Fig grows, we want to enable an ecosystem of UI extensions for the terminal that are built to go cross platform. Using web technology here made sense since we can leverage built-in webviews for rendering or bundle a lightweight implementation like Tauri[0].

[1]


I don't understand this response, so let me rephrase my question.

This page https://fig.io/docs/getting-started says that Node.js and NPM is required to use Fig. I presumed this meant that Fig was written in JavaScript, but you're saying it's native. Then why is Node required? If you're using web views for UI, wouldn't those web views on each respective platform already have their own JS engines?


> Linux is definitely not an after thought to us!

Care to share more about this? Which terminals are you planning to support?


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


The aws-cli is a monster! This exactly the type of situation where we envision Fig being really helpful :)


Speaking of, how did you generate the specs for the AWS cli and everything else? I wouldn't have thought that info is nicely laid out and documented somewhere.


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


As soon as I saw the title I anticipated the Dropbox conversation!

I’m guessing people like me who use the shell as a means to an end. Honestly most of the time I’m using git bash “coz it’s there” and hate typing in commands. I actively avoid it. I installed LENS for kubernetes to avoid it.

I’d rather write a script in an IDE and run that than be working at the command line. Because then I can treat it like code, review before running and it’s repeatable.

I really get the benefits of this tool but I won’t use it because I prefer to avoid excessive command line use - preferring GUI and scripts BUT I do get why it is useful if I have to do interactive command line sessions


Out of curiosity, do the scripts you write take options or arguments? Or are they generally just invoked directly?


Sometimes arguments and sometimes not.

Often the argument is simply test vs prod. So I can run it on my machine but also run it from Travis ci.

Any connections or secrets would be in the environment. For local I’d create another script to set them up and call the first script. Why? So the secrets don’t end up in the repo by mistake.


which oh-my-zsh plugins do you use that can do this? Is there an all-encompassing one or do you need to download tons of different ones like a docker plugin, git plugin, etc


I’ve been using grml’s zsh config [1] for years. It’s one file, I’ve never installed a single plugin, and it’s been doing a lot. Couple of examples:

- When I auto-complete a path, the shell prints all options and I can navigate between them with either tab or arrow keys

- For many tools, like git, auto-completion shows an annotated list of possible options/subcommands (and again, you can navigate them with tab or arrow keys)

- If I type something like chmod 644 and then start auto-completing the filename, the suggestions exclude every file that is already 644.

Also, there is a format to add auto-complete information for more tools. I’ve never actively used it, though, and I don’t know if it’s been adopted by any other shell/tool. I don’t even know if it’s specific to zsh or to grml’s config or to something else entirely. It has just stayed out of my way, while greatly facilitating my shell usage.

As a last point, none of these examples have been added recently. They have all been there for years.

This is not to pick on fig, but rather to show what zsh has been doing all along (and I suppose other shells like fish, too, but I’ve never tried).

[1] https://grml.org/zsh/


But I think it will be the same with Fig. They will take the autocomplete scripts from the vendors and integrate them with Fig.


They are totally different things. This is like asking why you need a computer at home when you already get the newspaper delivered every morning.


It's the other way around. Why buy this newspaper when I already have a computer?


Ok, sure. The analogy is silly anyway, but silly arguments beget silly analogies.


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?


Each needs to define an autocomplete script. oh-my-zsh provides plugins that do that for common tools like git.

Those scripts are usually supplied by the CLI tool itself. For example for terraform: https://www.terraform.io/docs/cli/commands/index.html#shell-...


This is the closest I see: https://github.com/ohmyzsh/ohmyzsh

Since switching to it from the default shell of Mac OS terminal (zsh I think) I have found it immensely productive. Some of the things it does seem Magic like auto completing uncommitted files when I say “git add <tab>”


https://github.com/zsh-users/zsh-autosuggestions


ohmyzsh is a plugin manager for zsh, not a different shell.


You need no tool at all as you can do I reverse search in any shell with ^R. If you want to do it with a better UX you can use fzf. If you want the suggestions you can use zsh-autosuggestions or fish shell. Setting them up is straightforward. And if you want an example config for Zsh you can look mine. Zinit, the package manager, automatically load/install the plugins when loading the shell.

https://github.com/danisztls/dotfiles/blob/main/shell/zshrc


Maybe https://github.com/junegunn/fzf


Fish does that by default


I really like Navi


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.


>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


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


Absurd? I'm definitely more confident that Fish/Zsh will stay free forever without changing their incentives, licensing and pricing than a YC-backed startup whose primary goal is to make money.


I generally try to avoid startups and either go for established companies (business offers are more likely to stay there and work as expected) or small bootstrapped business (cheap, more likely to stay true to their roots, do one thing well without breaking everything in the future).

Startups are good for free trials as they have VC money to spend or finished deals (purchase once, consume once, forget about them).


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?


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.


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


> 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


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!


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.


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.


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.


Requiring a work email is a common tactic for B2B sales, so that sales people can contact you and try to get you to buy. This doesn't seem like a B2B kind of product, so it does seem... odd.


The reason we suggest logging in with your work email is so that you can share shortcuts and completions for internal CLI tools with your team.

We should probably add this explanation to the login page because I can see how this would be confusing.


> The reason we suggest logging in with your work email is so that you can share shortcuts and completions for internal CLI tools with your team.

I guess I'm still missing something, as I don't get why the domain of my email address is relevant for who I share things with? My (hopefully constructive!) feedback is that by asking specifically for a business mail, you send certain signals to the end user.

Are you honestly saying that emails won't be used for sales purposes? (that might sounds a bit adversarial, but it's a genuine, non-judgemental question!)


No worries. We determine who is on your 'team' based on email domain excluding webmail domains, like gmail.com and hey.com.

If there are a bunch of people at the same company using Fig, we'd probably reach out to understand what you find valuable and how we could make it better - we don't have a paid offering yet, but want to figure out what teams are willing to pay for!


Ah, then it finally clicks. I really think you need to make this a lot clearer though. As others have already pointed out, if you're going to require this information, I think you need to ask for it up-front - don't ask for it at the end of the installer.

Something else I would add is that there are almost 300,000 people "in my team" using my business email domain (yep, it's a big company). I think better wording here would be "organization", rather than "team". But...

...I'm personally pretty unsure about this whole-company team/organization thing overall - for example, I work at a consultancy/outsourcer, and we can't just share whatever we want beteen divisions or teams. You've raised a lot of money (congrats :), and at some point you and your investors are going to want to make some money; so you can either charge individuals (which you've ruled out), or charge companies. Assuming the latter, and assuming you're going after larger companies with a lot of devs/sysadmins, I think your approach/presentation needs to be better tailored to that audience. If you're set on this "team" approach, I personally think it would be better to have it more like Slack (and many others), where someone has "ownership" rights for the team, and can manage its membership.

Thinking some more, I'm guessing your plan is something like: get as many individual devs/sysadmins on board for free, so they want it at work. If that's right, you need 2 better approaches/presentations: let individuals get it without barriers (like asking for business email...), and have a clearly separate paid plan.


Off-topic, but given that this hasn't gone too well, I'd love to read a follow-up from you. Like, how you change your product after getting the feedback here.


To those who, like me, are unwilling to share their email:

https://temp-mail.org


Ya I closed the app and removed the Accessibility permission at this step. I don't need this app to "connect with my coworkers"


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.


Early versions of Fig essentially used a keylogger to predict what you had typed in the terminal. This is not optimal from a security or product standpoint.

We have since integrated with the shells themselves (e.g. with zsh's line editor, ZLE for zsh). This allows us to get what you've typed more accurately and for your shell only. We are also working on new integration done exclusively through pseudoterminals.

Both of the cases above mean our Linux integration will simply be for window management!

You can see how all of our integrations with bash, zsh, fish, SSH, Docker etc work here: https://github.com/withfig/config


Thanks for the response! It's good to know you've moved away from that approach. I'm probably not one of your end users (I'd prefer an open-source or source-available client), but I look forward to seeing the progress you make on this.


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.


Wait. Does this mean that you are against the use of any tech product made by a company? From the description and the author comment it looks like they are not transmitting the keystrokes to their server (and it does not seem to have any need for it anyways). How is this different from using say, a compiler made by a company (they have access to all your code), or an image editor (they have access to all your photos).


If I can sign a binding contract that regulates how my data will be used for as long as I have this software then I'm happy to use most products.

Your examples don't capture what is happening here. Fig is freely downloadable, with implicit terms of use. They can say whatever they want in HN comments, but that has no bearing on what the software will actually do. If I buy a compiler, I get explicit terms of use. If I use an open-source compiler, I know what I'm using and I can change it if it's doing something sketchy, or roll back if it updates in some way I don't like. I wouldn't use a proprietary compiler I didn't pay for. Image editors too. And you can bet I wouldn't let either of those use the network (why do they need to?)

Moreover, the potential harm of my code or my images being leaked is much smaller than every keystroke into the terminal being leaked. Not even saying anything about Fig requiring access to other aspects of your machine too. So even if Fig did have a binding contract I'd be wary, because if the app gets exploited the consequences could be devastating.


Theoretically you are right. I wouldnt give Fig access.

But the world moved on without us.

Lets be honest: For 99.9% of users, no misuse ever happens which they care about.


I disagree in part, because this tool is not meant for the common user.


Is there another way to achieve what the product tries to do? Genuinely asking.


This covers most of the listed features.

https://github.com/Aloxaf/fzf-tab


I know about zsh-autosuggestions and fzf - I wanted to ask that as a developer building something like Fig, is there a way to build the same thing with less permissions than they currently have?


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.


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.


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.


>Well, this is an ad.

This isn't that eye-opening considering Launch HNs and job hires for YC-funded startups are said to be ads in FAQ.


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.


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


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


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.


I think you should reconsider daily pinging still taking place when the user explicitly asks to disable telemetry.


Disable except for once a day is not actually disabling. That's pretty whack.


Please make telemetry opt in, not opt out. And please honor the disableTelemetry setting by disabling the ping.


...DNT header, but for the OS


Telemetry by default in terminal autocompletion is a pretty big turnoff for me, even if it can be disabled


> Please excuse my paranoia.

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


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


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.


I am with you. Imo the shell is where I go to focus. Not constantly get distracted by colors and popups. Also, I don't need a VC backed disingenuous tool spying on me


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


Totally agree! The closer autocompletion lives to the source code, the better.

We've started off writing completions by hand, but to scale we will need more robust integrations. For instance, aws has 100+ subcommands and thousands of options.

Long term, we plan on writing integrations with popular CLI libraries, so that the completion spec can be generated automatically. We've already started with oclif[0] and have done some preliminary work with cobra.

[0 https://github.com/withfig/oclif-plugin/blob/main/src/comman...]


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.


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


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.


Why does this comment not seem legit... This seems like a bot. There is no way Apple or Microsoft would pick this up.


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.


Thanks for the feedback :)

If you run into bugs or gave any suggestions, run `fig issue` to quickly create a new Github issue!


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.


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


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.


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


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


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?


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.


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


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


Please support actual open source projects. The money here will just go to VCs pockets


Sorry but isn't this a message board on a VC website?


That point is not invalidating the parent's.


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


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!


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?


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…


There are some clearly cool parts to this. But it makes me feel like rather than bolting this onto existing terminals and shells, one should be created from the ground up to better integrate UI. Why not have actual abilities to show photos in an interactive way (eg ls giving me a grid of photos I can click and zoom on like Finder), or put in form values rather than just autocomplete like ffmpeg giving me an actual UI to work with that shows frame by frame progress rather than just a % bar?

The CLI seems ripe for total disruption IMHO. Fish shell claims it’s finally the terminal for the 90s… how about the 2020’s?


We totally agree! This is exactly where we want to take Fig.

The autocomplete product is built using an API that extends terminals with visual apps and shortcuts. Using the same API, you can build an app that interactively displays photos or wraps a common ffmpeg workflow.

We prototyped[0] a bunch of ideas like this during YC last summer, before deciding to start with autocomplete.

[0] https://fig.io/videos/old-sizzle-reel.mp4


I guess I’m suggesting why fix yourself to iTerm etc when you could just redesign the entire experience from scratch? You’d have way more freedom to fundamentally change CLI I/O, navigation, contextualization, UI, media support, etc.


How did a startup with such an obvious idea get started in 2020?

Was some API added to Mac recently that made it possible? Has the software market gotten large enough to support more niche products? Or just no one did it before?

I find it positive, comforting even; it suggests that the space of viable startup ideas is really vast.


I honestly feel the same way. Once you use Fig, it feels like such an obvious idea. It didn't require new APIs or anything like that.

As far as I can tell, no one tried it because to 10x the existing shell experience requires working across multiple layers of stack. You need integrations with the shell, the terminal emulator and the OS -- in addition, to mapping the structure of a bunch of CLI tools.


You sold me within 30 seconds of downloading. Yes, I know there are options out there for enabling autocomplete in my terminal, but I have no time to futz around with that stuff, and it still doesn't work when I ssh into a new server, while this is really, really easy to setup and "just works" everywhere. Spent 60 seconds installing, and I can easily see the immediate ROI shaving off several brain cycles every day as I spend a few hours in the terminal.


That's awesome to hear! Glad that everything is working!


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?


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"


Hi, you are a private company, so people will wonder what the "catch" is. I think your website should make this immediately clear and explicit (even if you don't know your future business model, you should just say that.) This is such an obvious question that it comes across as a bit dishonest to omit it. As an audience, terminal-loving programmers are a group that will swallow a commercial product only if it is being completely transparent.


I want to throw out something I had thought about while deep (deep) into fixing a broken server yesterday and having had a few thousand tabs opened over the course of 24 hours searching for every possible Linux command under the sun.

Here’s what I’d like, and it’s not really autocomplete. It’s more of a spotlight/Alfred combined with documentation and status panes.

Imagine someone frantically debugging two things: why a lot of their server is broken, and also why a disk is suddenly going slow but only sometimes, and only within docker. In fact, go ahead and just set up an Ubuntu server, run a small stack on it, plug in a slightly failing HDD, and then mount it to /var, wiping out the folder (and then only recovering part of it). Then, try and fix it using only Google.

I want a binary I can install that acts as a spotlight that lets me fix it without needing to leave the CLI. It’s not autocomplete, it needs to be much better. I could see a bin that basically pulls up a full screen search, where I can type natural language and see not just commands but specific usages. If it used data from StackOverflow that’d be great. If it also just helped debug the system health that’d be even better.

Anyway, I went on this little odyssey over the weekend and I’ve convinced myself something like this would be incredibly valuable. There’s a real cost switching to the browser and waiting for long network times. Plus history | grep + copy pasting is a lot slower than if I had a HUD with fuzzy search across historical commands + a database of all useful commands.

Of course once you add in the cost of supporting every platform it gets enormous, but then again you’d have really specific info on the platform to make it much easier to customize.


Here's a tip to anyone developing something like this: MacOS exclusivity will drive developers away from your program.


When it required me to enter my "work email" to "connect with teammates" before I could use it, I dragged it to the trash.


You are clearly not the ideal customer profile.. my guess is that the Fig team are going after corporate developers who won’t be as concerned about privacy so much as they are concerned about convenience and productivity.


What does this even mean? Pushing a Mac-exclusive app is hard enough, now you're further delineating between different "customer profiles"? It's an open-source app, it's "customer profile" is everyone with the means to install it, and their developers are the same people who use it on a daily basis.

Even still, your purported "corporate developers" would probably be more interested in privacy than your typical client, considering that corporations literally pay tens of thousands of dollars for proprietary tools like this, just so they have someone to hold liable if it breaks.

In either case, privacy is not a choice when you're working this low on the stack. You need to be operating with the lowest possible performance and telemetry options, or else you start to compromise the value proposition of your product. I wouldn't be surprised if this comment section acts as a good wake-up call to the core development team to switch their priorities, because developers don't agree with their current paradigm.


As someone with the misfortune to work in a large enterprise, this doesn't make sense - corporate are very sensitive to data leaving their network. As just one example, the place where I work very rarely let's us use anything cloud-hosted (Slack is just one example). And when the do, it's a years long process to get it.

I haven't looked into how this works, but if it's sending keystrokes or command lines to the cloud (one of the founders is here, please do correct me if I'm wrong!), it has no chance of being used in your average corporate environment.


^this. At least at FAANG , you will get flagged by opsec using a tool like this. Also, I don't think engineers here need something like this to be productive, nor having the same email domain means they use the same tools, but maybe is just me, as other people said, there are other tools that provide autocompletion, offline and free(as in speech). But maybe if you get PG to say this product will be the future of development, people will buy into it. I truly wish the founders the best of luck.


I want to add something a bit more positive - if you come with an on-prem version, it will have much more of a chance to sell within the enterprise. Of course, that's a lot more hassle to support etc.


Exactly. Having data leave our network (major corp environment) is a huge issue. Even when we are working with vendors, data comes in, but rarely, and only with many levels of authorization does it ever leave.

Any tool that is sending any information to the cloud is DOA for our org.


I actually care very little about the privacy issues, and am often very willing to trade privacy for convenience. I just don't want to be bothered to have to essentially register to use the app, for no real benefit to me.


When you login with your work email, you can share shortcuts and completions for internal CLI tools and scripts with your team.


Neat! A bit ago, I wanted something similar, so I glued company and pcomplete in an Emacs eshell https://xenodium.com/eshell-pcomplete-company-completion


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!


That's exciting! Is there a place I can sign up to be notified when it's released?


Yes! Linux: https://github.com/withfig/fig/issues/34 Windows: https://github.com/withfig/fig/issues/35


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!


Well, that's a good idea!


Fig's integration for Makefiles makes my life so much easier!

I've played with shell autocompletion before, but this way easier to use. Good luck!


Thanks Ramiro! Glad to hear you're finding Fig useful :)


I see a lot of negativity here, and I do agree about the daily ping which I see you’re removing, which I think is a good move.

As someone that has done cloud development at a giant corporation that offers public cloud, I think that this tool absolutely has an enterprise use case. In my particular experience at my particular (tens of billion dollars plus yearly revenue) previous employer, our SREs would have massively benefitted from having this. I’ve been woken up at 3am while on call for L3 support just to step out SREs through tools we wrote to help them do their jobs that we failed to adequately train them on and/or that they didn’t have the bandwidth to absorb due to the volume of services they were tasked to support.

From that point of view, supporting macOS first is the right move in my opinion because at enterprises developers are standardizing on macOS, and so are SREs.

This can solve a real pain point. Best of luck! And if it may happen to be helpful, let me know if you’d like to chat about this use case in more detail.


This is pretty cool!

I've only poked with it for a few minutes on a spare laptop I use for vetting software, but I did notice that the Kubernetes autocomplete only goes halfway, at least in iTerm.

If I do `kubectl top` it doesn't recommend `kubectl top pods|resources` in the autocomplete. Autocomplete needs to work for the whole line, not just the first argument.


It looks like this is an issue with the completion spec for kubectl[0]! I'm not super familiar with k8s, so you wanted to help fix this (eg. writing the generator to list pods) that would be amazing! <3

[0]https://github.com/withfig/autocomplete/blob/2a0eea63d04f6b2...


So I tried this with a throwaway address, disabled telemetry, and liked what I saw. Then noticed over the following few hours that text input everywhere other than iterm was very janky. Pauses, skipped letters, etc.

Disabled fig and it cleared up... Just FYI in case anyone else runs into this.


Thanks for reporting this. This is definitely not the expected behavior. Would love to figure out what was going wrong.

matt [at] fig.io


Setup is very smooth. I'm impressed how well this integrates with my macOS. Also a bit suspicious, but unless/until there's real evidence, honestly I think it's just because of VS funding + how well the setup / integration went.

Linux and especially smaller Unixes is where tools like this are really useful. My experience with Linux is that most stuff has to be installed on the command-line, or if there is a GUI it's clunky and/or missing features. And I would consider myself moderately experienced with the macOS Terminal, but I often got stuck / slow with Linux.

I really hope they add support for IntelliJ and other integrated Terminals. I'm pretty sure I end up using those a lot more than standalones.


Thanks! We currently work with the VSCode integrated terminal and will add support for Jetbrains IDEs, if possible!


I've been using xonsh, which also has autocomplete for a lot of things, and I LOVE the python shell because bash syntax is very alien to me.

The screenshots of fig look awesome, especially the git syntax and things, but my main feedback is I can't figure out what the hell fig is.

> git clone https://github.com/YOUR_GITHUB_USERNAME/autocomplete.git fig-autocomplete

> npm install

First reaction is WTF? I thought Fig was going to be some bash replacement that does autocomplete and was hoping to ask for a matching xonsh replacement.

But why do I need my git username and npm to have autocomplete in the shell?


To get autocomplete working, you just need to install the macOS app. (https://fig.io/hn)

These instructions only apply if you want to develop your own completion specs and are setting up the dev environment!


Oh I see. I use Linux, so I guess this isn't an option.


I love this concept! Especially that you are crowdsourcing completions, so some of the more niche ones can still get built.

Thank you for putting so many examples on your landing page. This seems obvious but so many landing pages don’t show me actual examples.


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.


Made me want to give a shot at writing a custom bash completion script for an internal tool (having a lot of sub-sub-commands and many options, kind of like git). How hard could that be?

Then I looked at git-completion.bash [1] and suddenly all my motivation vanished. Maybe Fig found a more declarative way of describing a tool's syntax?

[1] https://github.com/git/git/blob/master/contrib/completion/gi...


I am a big fan of Fig. Some of my favourite specs are `docker` and `git`. No longer do I need to list containers or commits before performing an action, the autocomplete provides all of these values for me.

I'm excited to see more command-line tools provide metadata about commands close to the source code. Our CLI at Fastly provides JSON output in the help command, so it was really easy to generate a Fig spec automatically: https://github.com/kailan/figly


sounds awesome, but seems very dependent on the app? for example I use hyper.is as my terminal, I've installed Fig but it doesnt seem to work? does this app only work on the default mac terminal?


We do integrate with Hyper. Does Fig work in other terminals for you?

Or are you potentially on the canary build of Hyper? (You can check in ~/.hyper.js)


it works now and works in other terminals, thank you. see other response for my alarm...


Our server also crashed when we first posted this.

Try running `fig update` in your terminal. This will download the most up to date version of Fig's completion specs


ah ok so you got hugged to death, nice.

but... why is Fig phoning home to your servers when i'm typing? what's local and what's not? this is alarming. does it go down if i am offline or have "lie-fi"?


Fig does not "phone home" when you type!

When you install Fig, we download the most up-to-date completions specs using the Github release API. (You can see them in ~/.fig/autocomplete). We got rate limited this morning (thanks HN!), so some people downloaded Fig, but didn't have any completion specs available.

Don't worry: all of the completion happens locally on your machine. None of your keystrokes or raw text from your terminal leaves your device.


I had seen another platform doing this - https://kloudi.tech/

I am not related to them in any ways. This happen to remind me of that too.


This is dubious. I am not going to be using this. I just randomly typed in my password in my terminal. Would have ended up in the hands of some VC. No thank you.

You can say that this is great mongering but the dubious claims around no telemetry (which were fixed after HN feedback) and the closed source completion engine and calling it open source is not trust inducing at all.

Man page hunting, jumping around help commands is how you learn things. You don't get Unix in one day and definitely not worth graphics. I say that as some one who is a visual learner.


How do you make a company out of this?


From their jobs page [1]:

"We've raised several million dollars from amazing VCs like General Catalyst and Kleiner Perkins, and angels like Jason Warner, Adam Gross, Olivier Pomel, Scott Belsky, Will Gaybrick and a handful of other impressive dev tool founders and executives."

[1] https://boards.greenhouse.io/fig


Docker raised even more money. Devtools monetization is the hardest problem in the startup world. It's been tried again and again because lots of startup founders are devs and they want to solve their own problems but ultimately nobody wants to pay for it


I think they mean “how do you steer this into a profit” rather than “how do you get investment”.


I think it's worth mentioning tldr as an effort towards more readable man pages: https://github.com/tldr-pages/tldr

Personally I like tealdeer for a tldr client b/c it's written in Rust and I think the name is fun, but the other tldr clients I've tried all seem fine as well: https://github.com/dbrgn/tealdeer

tldr doesn't do autocomplete, but between fish shell's autocomplete and tldr I feel I'm able to figure out most simple commands in the terminal.


Been using Fig for a few months now, and really can't see myself living without autocomplete for git branches and npm packages


This looks brilliant, but...

Sending CLI input data, even just the root command, back to Fig is going to be a deal breaker for a lot of companies. Too high a risk :-/

If you don't need that data, don't collect it. I am sure it will lead to interesting analysis, but it will also leak a lot from companies who are unwilling to let that stuff leak.


Thanks for the advice! We have a telemetry opt-out which turns this off.

Currently, we would still send a daily ping so we can track retention, but after the feedback from HN, we'll turn this off as well.


Looks really cool, but I would always use zsh-auto-complete. Maybe your market is for people that prefer GUI's over terminal, but like terminal power, or the newer generation of coders who went to code school and are not the older school terminal in the weeds people (sorry for a generalization)


> Looks really cool, but I would always use zsh-auto-complete.

Thanks for this feedback. Would love to dig in a little more here. What is it about Fig that turns you off? Is it the idea of having a GUI in the terminal?


I just downloaded it.

It's not so much the GUI in the terminal. I actually think it looks pretty slick. It's what I give in exchange - accessibility permissions are a big no no. And of course, verified email for a CLI utility is pretty much unheard of.


To me I think it is the antithesis of a developer tool. ZSH auto complete works 99% of the time for everything. FIG, while cool, seems more like a capitalistic way to capture developers who like fancy new things, when the open source, free, tried and true works every time. Once again, I dont speak for all devs, and I am an AVID terminal user, so I like to keep things simple, free, and open. This product and why you created it and what you are going to do with it makes me cringe :(


This is cool, is the idea to eventually develop a full-blown terminal too?

That seems where most of the value is to me, like you can't just make a 10x car by attaching stickers to an existing one, eventually you are going to need to redesign the whole thing, the same is probably true for terminals too.


Thanks so much!

Yes - we would love to build our own terminal one day. I agree, a first party experience will make Fig much better. We think a good terminal needs to be fast, cross platform, customisable, and extendable (this is easier said than done).

That said, one day we hope to build team-based tools too. Developers like to choose their tools - we would love to make Fig work, even if you weren't using a Fig terminal. We likely will also do the hard work of integrating with the existing terminals. You choose your tools and Fig is an integration on top.

If you're interested, here are some of the things we plan on expanding into. https://fig.io/videos/old-sizzle-reel.mp4


This video was helpful to see. I do like the idea of being able to enter arguments in a form and get the full command, especially for complex scripts. An obvious extension would be pulling out argparse info e.g. from python scripts and letting the user enter arguments via a form


> An obvious extension would be pulling out argparse

Yes absolutely. A lot of possibility. We hope to create a whole new way of building terminal apps!


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`


Iterm can do this for you as well


TIL... !


How?


cmd + ;


Is this intended to be a for-profit business? A business that just does autocomplete in the terminal? I'm surprised there is a market for this, but I'm not a mac user so I'm not very familiar with its users and ecosystem.


Just chiming in on the telemetry issue, there are definitely situations where you could accidentally paste/type sensitive data into the terminal, so you'd need to treat any user data from terminal sessions as toxic waste.


This is our approach! Nothing you type in the terminal is sent to Fig precisely to avoid this type of situation.


That's nice but, seeing it's backed up by investors, what's the monetization plan for this? I don't think people will pay for support for such a tool so selling binaries or extra features to paying customers?


I tried it - and I (despite having ohmyzsh installed) like it!

One thing I was wondering: How does the - largely critical, much negative feedback involved - discussion here on HB impact your download numbers? Is it positive after all?


Interesting take on ideas well presented in a blog post, dubbed as "CLUI": https://blog.replit.com/clui


There's an overabundance of useless tools by con-men these days.


Just curious! How are you planning to make money as a YC company?


We plan on adding collaboration features for teams in the future. Autocomplete will always be free for individuals!


Is < 50ms considered fast? I recently tried out xterm and I felt the decreased latency compared to my current alacrity setup. I’d love a modern terminal that’s fast too


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

This is excellent! :)


Congrats on the launch! Exciting to see all the progress


I have just one question: will this work over ssh? So when I run this on my Mac to do a git commit via ssh on a server, will autocompletion work?


Yes it will!

See this example: https://fig.io/images/slideshow/screenshots/ssh.png

It should work out of the box, but you may have some issues if you have multiple SSH connections to the same remote machine or if your remote machine uses an async prompt (like powerlevel10k).

If you have any issues, feel free to email me and I'll help get you set up brendan AT fig DOT io


How do you tell when a project only works on a Mac? It has a pretty marketing website and never mentions it's operating system support.


Is this the kind of startup that competes with git shortcuts? I can replace "git push origin master" with "git pom"...


Tried it for a few hours. Unfortunately, it randomly stops working all the time. Debugger says "key buffer context lost".


I am disappointed. I've been on your waiting list, you told us to watch for HN announcement, and it's still walled.


Did you use this link: https://fig.io/hn ?

Let me know if you still can't get access. matt [at] fig.io


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!


macOS runs an older version of GPLv2 GNU Bash. The newer GPLv3 GNU Bash has much better autocomplete built-in and many useful features (like |& for unified stdout/stderr redirect). Install it like this:

    brew install bash


macOS switched from bash to zsh a few years ago...


Zsh autocomplete is much slower than Bash autocomplete.


May be the setup you used. Too many plugins may make the shell unresposive. Anedoctally I autocompleted `ls /etc/` on zsh with a few plugins and on a bash with minimal setup. They were pretty much instantaneous. Maybe zsh was faster.


I've been using Fig for months now and it's become a must-have on my machine. I particularly love the git branch, npm package and yarn command autocompletion — my previous zsh plugin didn't have those and I use them all day every day.

Disclaimer: I invested in Fig recently because I'm such a fan.[0]

[0]: https://mxstbr.com/investing


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.


Not yet, but we are working on integrations. Want to subscribe to the relevant issues:

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


Uninstalled, sorry. Until a 100% offline version is available I'll watch from the sidelines.


Is Fig patenting this? How does the company prevent itself from being f.lux’d?


Autocomplete is just our first product. We've built an API that makes it possible to add visual extensions to any terminal.

We want to expand into stuff like runbooks, UIs for deployment, internal infra, etc..


I wish you the best. It’s a nice product.


What happened with f.lux?


The fuzzy completion tool fzf and a handful of zsh plugins cover all my needs.


You seem to have raised a fair bit of money. What's your business model?


What is the business model? Is this going to be a paid tool when out of beta?


Autocomplete will always be free for individuals. We plan on charging for team-based collaboration, like private completion specs for internal scripts and CLI tools.


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.


Congrats on the launch!


Will there ever be advertisement in the autocomplete results?


Nice onboarding but I don't like the email requirement.


This is awesome, when will you support linux and WSL?


DOes anyone know if this works with hyper.js?


We should! Are you running into issues?


Not for my terminal or anyone else who uses gnome terminal or any Linux terminal.

If you have money then maybe you could actually fork gnome terminal. Just make sure it's GPL.


Does this work on mintty (cygwin)?


Currently, Fig only supports macOS.


God bless yall, this was so needed


Glad you're liking it!


I need this for Linux!


We are planning on going cross platform! What distro / terminal emulator do you use?


I use kitty on Linux Mint (Ubuntu based)

https://sw.kovidgoyal.net/kitty/

Kitty has a terminal graphics protocol

https://sw.kovidgoyal.net/kitty/graphics-protocol.html


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.


Patrick from Replit here. Excuse the self-promotion, but if you're curious how Fig got started by building their MVP on Replit, check out their interview on our blog: https://blog.replit.com/fig.

Edit: And of course big congrats to Matt and Brendan on the launch! It's been a lot of work and a long time coming. You've built a great product!


So it's basically a Tab?


Here, with naive founders building the ultimate fruit-fly startup with no business model, YC has finally jumped the shark and become a cliche of itself.


I like the design of the tool.

But I don't understand why the primary target of a CLI tool would be macOS.

AFAIK macOS is not really a developer friendly ecosystem and most devs are using either GNU/Linux or Windows to run their workstation...


All the developers I know run macOS. The major San Francisco companies are predominantly macOS for developers.


That explains a lot :)


Mac is very popular with devs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: