Live data from Hacker News

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

fig.io

351–360 of 390 posts

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

#351

Earlier quoted context omitted.

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.

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.

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

#352
post #350

Earlier quoted context omitted.

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?

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

#353

Earlier quoted context omitted.

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.

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

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

#354
post #6

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?

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

#355
post #349
post #172

Earlier quoted context omitted.

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 d…

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

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

#356

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

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

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

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

#357

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.

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

https://temp-mail.org

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

#359
post #93
post #56

Earlier quoted context omitted.

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.

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.
Post reply on HN