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.
Launch HN: Fig (YC S20) – Autocomplete for the Terminal
111–120 of 390 posts
Re: Launch HN: Fig (YC S20) – Autocomplete for the Terminal
#112Re: Launch HN: Fig (YC S20) – Autocomplete for the Terminal
#113Re: Launch HN: Fig (YC S20) – Autocomplete for the Terminal
#114macOS 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
Re: Launch HN: Fig (YC S20) – Autocomplete for the Terminal
#115This 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…
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?
Re: Launch HN: Fig (YC S20) – Autocomplete for the Terminal
#116What is the business model? Is this going to be a paid tool when out of beta?
Re: Launch HN: Fig (YC S20) – Autocomplete for the Terminal
#117I 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?
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…
Agree RE bash but at some point doesn't one just use the tool with the featureset one wants?
Re: Launch HN: Fig (YC S20) – Autocomplete for the Terminal
#118macOS 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...
Re: Launch HN: Fig (YC S20) – Autocomplete for the Terminal
#119Earlier quoted context omitted.
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)
> 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?
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.
Re: Launch HN: Fig (YC S20) – Autocomplete for the Terminal
#120I 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)…
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