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

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

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

The reason we created our own standard is because traditional shell autocomplete doesn't always provide metadata, like descriptions, priority or icons. Also it is a little tricky to write by hand, unless you're pretty familiar with shell scripting.

For python argparse, there is argcomplete in the same vein

Then it just comes down to the Fig popover UX.

[0] https://github.com/withfig/oclif-plugin

(one of the reasons I would not want this tool, colors and file extensions are sufficient for types, no need for icons, popups, and yet another tool)

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

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

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

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

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

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

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

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.

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.

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.

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

That would be a completely useless metric.

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

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

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.

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.

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.

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

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

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.

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?

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?

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

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

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.

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.

Canonical already does this.

* 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

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.

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.

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

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

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.

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.

Our macOS approach might not work everywhere.

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.

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?

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.

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

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?

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

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.

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

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.

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.

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?

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.

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

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]

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?

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

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.

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

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.

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

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

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/danisztls/dotfiles/blob/main/shell/zshrc

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

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

Can those who know what zsh mean do a better job with existing tools or custom made scripts? 100%, but that doesn't matter.

Beyond that, you can level up even further by firing up Emacs and never again needing a terminal for things that require completion.

If they use their institution's infrastructure, it's managed by the dedicated system admins. No way they're going to allow this tool to be installed.

I spent 10 years in the kind of academic setting described. A LARGE part of the work of the people in this example do their work on ordinary self-managed laptops without a sysadmin in sight (and probably very little common language in which to even begin communicating with a sysadmin, if they even know what a sysadmin is). The amount of time that is wasted by ordinary researchers being very uncomfortable with the terminal is staggering. Although I was/am a researcher in my own right, I do feel that I had an order of magnitude greater positive impact on research by helping out the approximate dozen of other researchers around me do their terminal and programming work more efficiently/better/smoothly/reliably.

I definitely think there's huge room for improvement in this area. But I don't think something like Fig is the answer; safe and effective use of Fig seems to require enough wherewithal to ask someone (or google) how to set up bog standard autocompletion solution in the first place.

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

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.

Agree RE bash but at some point doesn't one just use the tool with the featureset one wants?

It should be pretty easy to 'compile' a Fig completion spec down to zsh, fish, or bash. This is actually something I've been meaning to write!

This image may help clarify: https://fig.io/images/slideshow/screenshots/ssh.png

That said, it's pretty attractive because it's much harder to make a case to install fish on remote servers.

if I type 'sudo cp ' will it run 'sudo ls' to offer suggestions?

this...is not good. my terminal should not be executing code on my behalf on remote servers I've SSHed to.

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

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

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

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!

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.

https://temp-mail.org

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.

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

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.

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.

But the world moved on without us.

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

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

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.

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.

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.

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

However, Is there someway I can make Fig not send any data to anyone else? From what I understand, Fig does send telemetry information, but I'd like to be made aware of it before it asks me to give it "accessibility" powers.

Also, while Fig may not send the data to anyone. Does this also cover all the auto-completion scripts? I'm worried I'll need to audit each one.

(I haven't gone past the grant accessibility powers screen)

You can run `fig settings app.disableTelemetry true` to disable all telemetry except for one daily ping.

You also make a good point: in our onboarding we should move our privacy information to before granting accessibility! We will make this more clear

> You can run `fig settings app.disableTelemetry true` to disable all telemetry except for one daily ping.

contains such a blatant lie (disableTelemetry does _not_ disable telemetry) that I've already lost a lot of trust, in an area I am not willing to play trust games. I hope you rethink this, soon and loudly.

It was also more than a little controversial.

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

Also, this experience really is great. Without knowing anything I was able to disable the "Menubar Icon" simply by guessing commands.

And to try for any constructive feedback, I personally don't like logo at all. It doesn't seem to make sense to me and is the reason for hiding the icon in the first place.

Feels like a window management icon like this: https://magnet.crowdcafe.com/

Great job, will follow this closely!

VSCode terminal should be supported out of the box. Go to ◧ > Settings and make sure the VSCode Integration is ticked. (You may also have to restart VSCode.)

re Fig's icon: haha yes we could definitely do with a new icon. Our previous icon was an emoji pear (yes a pear, not a Fig) so at least our current one is a step up from that! We take the feedback on board and will investigate some new logo designs

I swapped my builds and it's working perfectly, thank you and good luck to you and the team.

If it's different, want to create an issue for us and we'll get to it this week? https://github.com/withfig/fig

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

My only worry would be this is obviously so great it's only a matter of time before Apple/Microsoft see the light and build something similar into their OS - however hopefully this happens via acquisition rather than what happened to Flux, Watson and Duet.

1 - https://xon.sh

2 - https://i.imgur.com/p8TFdKv.png

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

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

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 find it disingenuous as it makes users feel as if they're being offered something "for free" only to pull a "gotcha" after I gone through a lot of steps to reach the end of the installation process.

I feel it's far more candid to place the email gathering step at the start of the process so I know "okay, these guys aren't charging money, but they do at least want an email address to use this software". From there I can base my decision on how comfortable I am with providing my email address without going through the work of downloading, installing and updating system privacy settings first.

I completely understand the need to build up a list of client email addresses and that nothing in life is free, however; I think this should be done in a more tactful way that doesn't make me feel like I am have been "cornered" into providing my contact details at the end of a lengthy installation process.

Additionally; I think it's questionable that you hide the fact that you track users behind a low-contrast drop down in the installation process, and that tracking is switched on by default. I should be able to opt out before the installation process is completed and not be required to manually opt out via an arbitrary command that is difficult to remember after the installation is complete.

Finally; @mschrage - There's no doubt that what your team has built is beautiful and really nice to use. Thank you for sharing it with this commmunity and congratulations on your launch. I wish you the best on your journey and hope you'll reconsider some of these less-than-ideal patterns in your software.

You can receive email in temporary email inboxes :)

> That plus the fact that they do send data to their servers for some reason...

But the temporary email inbox is some random `[email protected]` inbox you find on the internet (not some inbox you create by your own)... so zero data about you is sent (if any).

You can see our full privacy policy here: https://fig.io/privacy

You will see my login name, the structure of my folders and my intent to take over the world. Kinda sensitive, it seems.

edit: after switching back to university wifi fig also worked fine, so it may be an issue with the wifi or there may be a need to refresh the network connection when trying to set everything up

We were getting rate limited by Github when downloading the newest completion specs earlier - that might have been the issue as well!

Is there a plan to support the completion APIs over LSP so existing tools can implement support independently? For example if I could write a language client for various language servers just for the completion apis, it would go a long way.

I'm surprised it requires nodejs on the client to run - how do you lock node versions so it doesn't break on updates, or needs to run in the same dev environment as older versions? If my dev environment has node locked to an older LTS, will fig still work?

As well, linux support would be great. So would a vscode extension so it can run in the integrated terminal, but I'm not sure if that's possible.

Also to clarify: we don't require node.js on the client. The completion specs are interpreted by the Fig macOS app.

re: LSP. Super cool idea, are you imagining Fig autocomplete in language-specific repls? Or something else?

Does the VSCode implementation run on Linux?

I’m having quite some trouble understanding why I would add a tool that potentially sends all my terminal to the web…

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

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

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.

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.

Even if it stays honest and never dark-patterns me, i expect at the very least the service will change in some way. Failing entirely, dark patterns, etc. My preference for simple products i can purchase gives me confidence that it will just work as long as i need it.

No criticism towards you - just giving feedback.

I like using companies where your relationship with them is obvious (ie I pay money and they give me services) rather than mysterious (Ie I use Google and they use my data in a way I don’t quite understand to make lots of money from me with me never paying them).

If the first monetisation strategy doesn’t pay off what comes next? Ads in the terminal? Increased telemetry to sell to companies? Sudden removing of features put behind a paywall?

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.