mschrage

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

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

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

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.

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

We should! Are you running into issues?

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!

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)

This makes sense. Thank you for the feedback! :)

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

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!

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

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

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

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.

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.

Just joined! Also love the idea of a headless shell. Excited to chat more

One of the things that we discovered when trying to build out a declarative standard is that it can never encompass everything, precisely because many CLI tools implement their parsing logic imperatively! Our solution was to start off with a declarative schema, that can be supplemented with an imperative escape hatch.

Glad you like the UI!

Cobra and other CLI libraries, like oclif, can help you generate the skeleton of the CLI, stuff like subcommands, options, etc. (I'm in the process of writing the integration so you can generate a Fig completion spec the same way!)

The difference is that with Fig you can add richer completions as well. For instance, Fig's completion for `npm install` allows you to search across all npm packages: https://twitter.com/fig/status/1385401292193865731

First off, I've been a big fan of Oil shell for a while! Love the blog. :)

Fig currently works with bash, zsh and fish. Since we are operating at the OS level rather than in the shell, we can get around the inflexibility of readline/bash.

In theory, this approach would work anywhere. What we do currently on macOS is especially 'involved' since we need to provide the completions UI in a separate GUI app that we don't control. But, in general, integrating at the OS/application level should be possible on Linux and Window as well.

Yeah, we don't want this to be a '15th standard' situation [0]

The biggest issue with traditional shell completions is that they are kind of tricky to build. Everything is defined imperatively and written as a shell script.

We wanted to lower the barrier to building completions and make a representation that works across different shells.

[0] https://xkcd.com/927/

The core focus right now is autocomplete, but this is definitely an area that we want to explore more in the future!

The TS/JS analogy is perfect. This is exactly the approach we took with Fig.

We defined a declarative standard that lets you describe the structure of any CLI tool. Fig then uses these to provide VSCode-style autocomplete in the terminal!

Currently specs are manually contributed by the community, but we are planning to integrate with CLI libraries (cobra, commander, click, etc) so they can be generated automatically!

You can see some examples here: https://github.com/withfig/autocomplete

We were inspired by this idea while building early prototypes of Fig (https://withfig.com) and wanted to bring rich interactivity/discoverability to existing terminals.

The goal is to layer on a CLUI style interface to all of the CLI commands you already use!

I started using Superpowered yesterday and it is great! (I'm so tired of waiting for Google Calendar to load!)

One feature request: it seems like it's not possible to create new calendar events using the app. I assume this is on the roadmap?

This is exactly what I’ve been working on with Fig. Intellisense exists in every modern IDE but not the shell.

https://github.com/withfig/autocomplete

This is something I’ve been working on!

Autocomplete popovers / CLUIs seem like a really natural way to enhance discoverability in the terminal.

https://github.com/withfig/completion-specs

Very cool! Congrats on the launch (site is super clean!).

This is a great question. We spent a lot of time making sure the Fig can be driven from the keyboard.

You can launch apps, search your shortcuts and toggle focus between the terminal and Fig all without touching the mouse. Our global hot key is CMD+I.

Each Fig app also has its own shortcuts. A few of the conventions we are trying to enforce across all of them are J and K for moving between inputs (tab also works) and the keyboard mnemonics you mentioned.

This is really interesting! I think that the scalable approach like you proposed in your thesis makes a lot of sense, but comes at some cost to the user experience.

Rather than being 'smart' and automating everything, we want to make developing apps really easy and familiar.

I'm curious what the biggest challenges were for you with the project? Maybe we could build on your research.

Yeah, these are both great ideas.

I was inspired to use web technologies for building the UI by this discussion (https://lobste.rs/s/vrb7qh/web_as_gui_toolkit). Ultimately, I want to port Fig to Linux and Windows, so having a UI layer that works cross platform is useful. But it would be very cool to enable access to native UI directly. (I'd love to chat with you about how this could work.)

Outputing to stdout and stderr doesn't happen right now, but is on the very near term roadmap. The ultimate goal is for web apps to slot in seamlessly to shell workflows, so getting this right is really important.

Thanks for your comments!