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.
416 karma · joined October 14, 2014
Our macOS approach might not work everywhere.
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.
If you run into bugs or gave any suggestions, run `fig issue` to quickly create a new Github issue!
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]
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.
These instructions only apply if you want to develop your own completion specs and are setting up the dev environment!
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!
We want to expand into stuff like runbooks, UIs for deployment, internal infra, etc..
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.
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 should probably add this explanation to the login page because I can see how this would be confusing.
matt [at] fig.io
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...]
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.
[0]https://github.com/withfig/autocomplete/blob/2a0eea63d04f6b2...
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.
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.
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!
Then it just comes down to the Fig popover UX.
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?