[HN Gopher] Launch HN: Fig (YC S20) - Autocomplete for the Terminal
___________________________________________________________________
Launch HN: Fig (YC S20) - Autocomplete for the Terminal
Author : mschrage
Score : 397 points
Date : 2021-05-25 15:09 UTC (7 hours ago)
(HTM) web link (fig.io)
(TXT) w3m dump (fig.io)
| gtf21 wrote:
| I 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?
| dangom wrote:
| 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 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.
| brendanfalk wrote:
| 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 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).
| gtf21 wrote:
| So wouldn't a better solution be to make a nicer DSL for
| describing shell completions which is then translated into
| zsh, fish, etc. completions?
|
| Agree RE bash but at some point doesn't one just use the tool
| with the featureset one wants?
| mschrage wrote:
| That's how we think about the completion spec standard. It
| essentially is a type-safe DSL that describes the structure
| of CLI tools.
|
| 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!
| skratlo wrote:
| > Fig's standard format
|
| 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.
| brendanfalk wrote:
| Yep I mistyped. Meant to say standard "suggestion" format.
| Trying to imply that each suggestion conforms to a specific
| standard that we have set but that lets you customise
| things like the text it suggests, what is inserted, icon
| etc
| yogevyuval wrote:
| What exactly do you mean by even when in SSH or docker?
| brendanfalk wrote:
| As in, if you SSH into a remote machine, Fig can offer
| completions for that remote machine. Same thing if you are
| running an interactive terminal for a docker container.
|
| This image may help clarify:
| https://fig.io/images/slideshow/screenshots/ssh.png
| krrrh wrote:
| This seems like black magic, but it really does raise a
| lot of questions about the telemetry issue. It's one
| thing to potentially leak information from your own
| machine, but leaking data from remote servers you ssh
| into requires a whole 'nother level of assurity around
| privacy.
|
| That said, it's pretty attractive because it's much
| harder to make a case to install fish on remote servers.
| [deleted]
| [deleted]
| woodruffw wrote:
| I 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) 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.
| brendanfalk wrote:
| Early versions of Fig essentially used a keylogger to predict
| what you had typed in the terminal. This is not optimal from a
| security or product standpoint.
|
| 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
| woodruffw wrote:
| Thanks for the response! It's good to know you've moved away
| from that approach. I'm probably not one of your end users
| (I'd prefer an open-source or source-available client), but I
| look forward to seeing the progress you make on this.
| fmakunbound wrote:
| How do you make a company out of this?
| ggregoire wrote:
| From their jobs page [1]:
|
| "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."
|
| [1] https://boards.greenhouse.io/fig
| Closi wrote:
| I think they mean "how do you steer this into a profit"
| rather than "how do you get investment".
| msoad wrote:
| Docker raised even more money. Devtools monetization is the
| hardest problem in the startup world. It's been tried again
| and again because lots of startup founders are devs and they
| want to solve their own problems but ultimately nobody wants
| to pay for it
| fancyfish wrote:
| I love this concept! Especially that you are crowdsourcing
| completions, so some of the more niche ones can still get built.
|
| Thank you for putting so many examples on your landing page. This
| seems obvious but so many landing pages don't show me actual
| examples.
| renewiltord wrote:
| Cool tool. I like this sort of thing. Some feedback:
|
| * 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.
| mschrage wrote:
| Thanks for the feedback :)
|
| If you run into bugs or gave any suggestions, run `fig issue`
| to quickly create a new Github issue!
| avinassh wrote:
| Congrats on the launch! How does this work?
| mschrage wrote:
| 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!
| WORMS_EAT_WORMS wrote:
| Any plan to support vscode terminal?
|
| 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!
| brendanfalk wrote:
| Glad you are liking it!
|
| 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
| WORMS_EAT_WORMS wrote:
| Ah, you're right! I am on the "VSCode Exploration" build
| still from being an early M1 adopter. I guess that version
| doesn't work -- no idea.
|
| I swapped my builds and it's working perfectly, thank you and
| good luck to you and the team.
| brendanfalk wrote:
| Glad to hear - is VSCode exploration the same as VSCode
| Insiders? If so, I believe we do support this too (However
| I guess the whole idea of Insiders is it is constantly
| being updated so maybe our integration recently broke).
|
| If it's different, want to create an issue for us and we'll
| get to it this week? https://github.com/withfig/fig
| the_arun wrote:
| Just curious! How are you planning to make money as a YC company?
| brendanfalk wrote:
| We plan on adding collaboration features for teams in the
| future. Autocomplete will always be free for individuals!
| [deleted]
| brianm wrote:
| This looks brilliant, but...
|
| Sending CLI input data, even just the root command, back to Fig
| is going to be a deal breaker for a lot of companies. Too high a
| risk :-/
|
| If you don't _need_ that data, don 't collect it. I am sure it
| will lead to interesting analysis, but it will also leak a lot
| from companies who are unwilling to let that stuff leak.
| mschrage wrote:
| Thanks for the advice! We have a telemetry opt-out which turns
| this off.
|
| 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.
| mschrage wrote:
| Hi HN! We're Matt and Brendan, co-founders of Fig
| (https://fig.io/hn). Fig adds VSCode-style autocomplete to your
| existing terminal.
|
| We built Fig because of our own struggles in the terminal: we
| were tired of context switching between man pages, Stack Overflow
| posts, and Medium tutorials anytime we got stuck. We wanted our
| CLI tools to be more discoverable.
|
| The terminal is powerful, but unforgiving. It emulates the
| constraints of hardware (like teletype printers and video
| terminals) that became obsolete a generation ago. There are no
| built-in affordances. No hints about the 'right way' of using a
| tool or even finding the right tool for the job. Beginners are
| thrown in the deep end. And even seasoned developers can screw up
| their system with a few unfortunate keystrokes.
|
| To solve this, we add a UI overlay that is linked with the
| interactive shell. As you type, Fig pops up subcommands, options,
| and contextually relevant arguments in your existing terminal.
| For example, you can type `npm run` and Fig will show you the
| scripts available in your package.json. You could also type `cd`
| when SSH'd into a remote machine and Fig will list the folders
| within your current directory on the remote machine.
|
| We use the Accessibility API on Mac to insert text on your behalf
| and read what you've typed. We also integrate with the shell to
| determine the current process and working directory. We are built
| natively for macOS in swift. We built our UI using web
| technologies so we can ultimately go cross platform. We render it
| using a WKWebView (not Electron).
|
| Fig is free for individuals and always will be. All completion
| specs - the templates used for generating CLI suggestions - are
| open source and anyone can contribute [0]. We plan to monetize by
| supporting autocomplete for companies' custom scripts and
| internal CLI tools. Ultimately, we want to bring other process
| documentation (like SRE runbooks or deployment workflows) closer
| to the environment where it's used. You can see an early
| iteration of Fig in this HN thread from last July. [1]
|
| Fig is designed to be private. All processing happens locally on
| your device. None of your keystrokes are ever transmitted or
| stored by Fig.
|
| We'd love to hear your feedback on what we've built! We're still
| in private beta (so things may break!!), but we are letting HN
| users skip our waitlist today and tomorrow using the link above!
| :)
|
| ---- Edit:
|
| We really appreciate all of this feedback! Brendan and I want to
| address some of the most common concerns below:
|
| Telemetry: Fig has basic telemetry in order to help us make
| product decisions. We currently give the you option to opt out of
| all non-essential telemetry by running `fig settings
| app.disableTelemetry true`. This removes everything except for
| one daily ping. We use this ping to help us understand how many
| people were using Fig.
|
| Adding this ping was a mistake. We have already removed it and
| will be pushing this change in our next build (v1.0.43).
|
| Business Model: Under the hood, we've built an API layer on top
| of the terminal. This API lets you create visual apps.
| Autocomplete is the first app we've built using this API. We have
| many more planned for things like interactive runbooks for SREs
| and automating deployment workflows. You can see some early
| prototypes here. [2] We plan to monetize these team-based apps by
| charging per-seat.
|
| Autocomplete will always be free for individuals. We will never
| sell your data.
|
| [0] https://github.com/withfig/autocomplete
|
| [1] https://news.ycombinator.com/item?id=23766980
|
| [2] https://withfig.com/videos/old-sizzle-reel.mp4
| shadeslayer_ wrote:
| I have been using zsh-autosuggestions [1] to achieve something
| similar, so seeing a new product that seems infinitely easier to
| configure and much more powerful is very.. heartening. I might
| not move over right this moment, but I'll be cheering you on.
|
| 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
| mschrage wrote:
| Thanks so much for this! We've heard the feedback on telemetry
| loud and clear - definitely will rework this in the future.
| duped wrote:
| This 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 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.
| mschrage wrote:
| Fig already works inside of VSCode and VSCode Insiders!
|
| 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?
| duped wrote:
| Exactly that. LSP is great because its the only semi-standard
| API for integrating with different programming tools, and
| completions are one of the built in features. Snippet support
| too - I can't tell how many times I've needed to write a for
| loop in a REPL, which would be much easier with snippets in a
| terminal.
|
| Does the VSCode implementation run on Linux?
| igammarays wrote:
| You sold me within 30 seconds of downloading. Yes, I know there
| are options out there for enabling autocomplete in my terminal,
| but I have no time to futz around with that stuff, and it still
| doesn't work when I ssh into a new server, while this is really,
| really easy to setup and "just works" everywhere. Spent 60
| seconds installing, and I can easily see the immediate ROI
| shaving off several brain cycles every day as I spend a few hours
| in the terminal.
| mschrage wrote:
| That's awesome to hear! Glad that everything is working!
| crazypython wrote:
| macOS 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
| djrogers wrote:
| macOS switched from bash to zsh a few years ago...
| crazypython wrote:
| Zsh autocomplete is much slower than Bash autocomplete.
| lobocinza wrote:
| May be the setup you used. Too many plugins may make the
| shell unresposive. Anedoctally I autocompleted `ls /etc/`
| on zsh with a few plugins and on a bash with minimal setup.
| They were pretty much instantaneous. Maybe zsh was faster.
| coltons wrote:
| Looks really cool, but I would always use zsh-auto-complete.
| Maybe your market is for people that prefer GUI's over terminal,
| but like terminal power, or the newer generation of coders who
| went to code school and are not the older school terminal in the
| weeds people (sorry for a generalization)
| brendanfalk wrote:
| > Looks really cool, but I would always use zsh-auto-complete.
|
| Thanks for this feedback. Would love to dig in a little more
| here. What is it about Fig that turns you off? Is it the idea
| of having a GUI in the terminal?
| arvindamirtaa wrote:
| I just downloaded it.
|
| It's not so much the GUI in the terminal. I actually think it
| looks pretty slick. It's what I give in exchange -
| accessibility permissions are a big no no. And of course,
| verified email for a CLI utility is pretty much unheard of.
| da39a3ee wrote:
| Hi, you are a private company, so people will wonder what the
| "catch" is. I think your website should make this immediately
| clear and explicit (even if you don't know your future business
| model, you should just say that.) This is such an obvious
| question that it comes across as a bit dishonest to omit it. As
| an audience, terminal-loving programmers are a group that will
| swallow a commercial product only if it is being completely
| transparent.
| Closi wrote:
| Absolutely stunning - I've often wondered myself about why the
| terminal doesn't behave like this already, it just _makes sense_.
|
| 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.
| wraptile wrote:
| Most terminals do behave like this, or am I missing something?
| Sure it has some nice extras like help messages and icons but
| those aren't that important, right? Even super niche shells
| like xonsh [1] has visual autocomplete [2]
|
| 1 - https://xon.sh
|
| 2 - https://i.imgur.com/p8TFdKv.png
| andiareso wrote:
| Why does this comment not seem legit... This seems like a bot.
| There is no way Apple or Microsoft would pick this up.
| chokolad wrote:
| There was this rather janky IDE for Powershell, way before
| VSCode even existed, called Powershell ISE, that had very
| similarly looking autocomplete behavior in it's terminal
| window.
| seniorThrowaway wrote:
| It's still around, I just used it today. I rarely use
| Powershell but when I do it helps (somewhat) to use this vs
| straight command line. I want to like Powershell but there is
| so much about it that just feels off as a long time bash
| script writer. I am admittedly a novice at Powershell though,
| so maybe it is just me.
| EamonnMR wrote:
| Just chiming in on the telemetry issue, there are definitely
| situations where you could accidentally paste/type sensitive data
| into the terminal, so you'd need to treat any user data from
| terminal sessions as toxic waste.
| mschrage wrote:
| This is our approach! Nothing you type in the terminal is sent
| to Fig precisely to avoid this type of situation.
| stephc_int13 wrote:
| I like the design of the tool.
|
| But I don't understand why the primary target of a CLI tool would
| be macOS.
|
| AFAIK macOS is not really a developer friendly ecosystem and most
| devs are using either GNU/Linux or Windows to run their
| workstation...
| fruityrudy wrote:
| Mac is very popular with devs.
| jitl wrote:
| All the developers I know run macOS. The major San Francisco
| companies are predominantly macOS for developers.
| stephc_int13 wrote:
| That explains a lot :)
| djrogers wrote:
| So I tried this with a throwaway address, disabled telemetry, and
| liked what I saw. Then noticed over the following few hours that
| text input everywhere other than iterm was very janky. Pauses,
| skipped letters, etc.
|
| Disabled fig and it cleared up... Just FYI in case anyone else
| runs into this.
| mschrage wrote:
| Thanks for reporting this. This is definitely not the expected
| behavior. Would love to figure out what was going wrong.
|
| matt [at] fig.io
| danielyaa5 wrote:
| Iterm can do this for you as well
| atdt wrote:
| How?
| anentropic wrote:
| cmd + ;
| anentropic wrote:
| TIL... !
| patrickscoleman wrote:
| Patrick from Replit here. Excuse the self-promotion, but if
| you're curious how Fig got started by building their MVP on
| Replit, check out their interview on our blog:
| https://blog.replit.com/fig.
|
| Edit: And of course big congrats to Matt and Brendan on the
| launch! It's been a lot of work and a long time coming. You've
| built a great product!
| jjwiseman wrote:
| When it required me to enter my "work email" to "connect with
| teammates" before I could use it, I dragged it to the trash.
| ttul wrote:
| You are clearly not the ideal customer profile.. my guess is
| that the Fig team are going after corporate developers who
| won't be as concerned about privacy so much as they are
| concerned about convenience and productivity.
| GordonS wrote:
| As someone with the misfortune to work in a large enterprise,
| this doesn't make sense - corporate are very sensitive to
| data leaving their network. As just one example, the place
| where I work very rarely let's us use anything cloud-hosted
| (Slack is just one example). And when the do, it's a _years
| long_ process to get it.
|
| I haven't looked into how this works, but if it's sending
| keystrokes or command lines to the cloud (one of the founders
| is here, please do correct me if I'm wrong!), it has _no_
| chance of being used in your average corporate environment.
| qshaman wrote:
| ^this. At least at FAANG , you will get flagged by opsec
| using a tool like this. Also, I don't think engineers here
| need something like this to be productive, nor having the
| same email domain means they use the same tools, but maybe
| is just me, as other people said, there are other tools
| that provide autocompletion, offline and free(as in
| speech). But maybe if you get PG to say this product will
| be the future of development, people will buy into it. I
| truly wish the founders the best of luck.
| GordonS wrote:
| I want to add something a bit more positive - if you come
| with an on-prem version, it will have much more of a chance
| to sell within the enterprise. Of course, that's a lot more
| hassle to support etc.
| cwdegidio wrote:
| Exactly. Having data leave our network (major corp
| environment) is a huge issue. Even when we are working with
| vendors, data comes in, but rarely, and only with many
| levels of authorization does it ever leave.
|
| Any tool that is sending any information to the cloud is
| DOA for our org.
| smoldesu wrote:
| What does this even mean? Pushing a Mac-exclusive app is hard
| enough, now you're further delineating between different
| "customer profiles"? It's an open-source app, it's "customer
| profile" is everyone with the means to install it, and their
| developers are the same people who use it on a daily basis.
|
| Even still, your purported "corporate developers" would
| probably be more interested in privacy than your typical
| client, considering that corporations literally pay tens of
| thousands of dollars for proprietary tools like this, just so
| they have someone to hold liable if it breaks.
|
| In either case, privacy is not a choice when you're working
| this low on the stack. You _need_ to be operating with the
| lowest possible performance and telemetry options, or else
| you start to compromise the value proposition of your
| product. I wouldn 't be surprised if this comment section
| acts as a good wake-up call to the core development team to
| switch their priorities, because developers don't agree with
| their current paradigm.
| jjwiseman wrote:
| I actually care very little about the privacy issues, and am
| often very willing to trade privacy for convenience. I just
| don't want to be bothered to have to essentially register to
| use the app, for no real benefit to me.
| mschrage wrote:
| When you login with your work email, you can share
| shortcuts and completions for internal CLI tools and
| scripts with your team.
| [deleted]
| azinman2 wrote:
| There are some clearly cool parts to this. But it makes me feel
| like rather than bolting this onto existing terminals and shells,
| one should be created from the ground up to better integrate UI.
| Why not have actual abilities to show photos in an interactive
| way (eg ls giving me a grid of photos I can click and zoom on
| like Finder), or put in form values rather than just autocomplete
| like ffmpeg giving me an actual UI to work with that shows frame
| by frame progress rather than just a % bar?
|
| The CLI seems ripe for total disruption IMHO. Fish shell claims
| it's finally the terminal for the 90s... how about the 2020's?
| deagle50 wrote:
| Sign in with your work e-mail?
| mschrage wrote:
| 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!)
| deagle50 wrote:
| Thanks, I installed it. Looks like neither Alacritty or Kitty
| are supported yet.
| brendanfalk wrote:
| Not yet, but we are working on integrations. Want to
| subscribe to the relevant issues:
|
| Alacritty: https://github.com/withfig/fig/issues/28 Kitty:
| https://github.com/withfig/fig/issues/26 More: https://gith
| ub.com/withfig/fig/issues?q=is%3Aissue+is%3Aopen...
| jcastro wrote:
| I need this for Linux!
| mschrage wrote:
| We are planning on going cross platform! What distro / terminal
| emulator do you use?
| thunderscore wrote:
| No GP, but I'm forced to use Windows at work, so an
| integration into Windows Terminal would be super great. I've
| also seen a lot of people use Cmder, and I would personally
| switch to Cmder from Windows Terminal if Fig was only
| available on that.
| mschrage wrote:
| 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 :)
| jcastro wrote:
| Standard stuff, ubuntu/gnome-terminal.
| shaicoleman wrote:
| I use kitty on Linux Mint (Ubuntu based)
|
| https://sw.kovidgoyal.net/kitty/
|
| Kitty has a terminal graphics protocol
|
| https://sw.kovidgoyal.net/kitty/graphics-protocol.html
| kailanb wrote:
| I am a big fan of Fig. Some of my favourite specs are `docker`
| and `git`. No longer do I need to list containers or commits
| before performing an action, the autocomplete provides all of
| these values for me.
|
| I'm excited to see more command-line tools provide metadata about
| commands close to the source code. Our CLI at Fastly provides
| JSON output in the help command, so it was really easy to
| generate a Fig spec automatically:
| https://github.com/kailan/figly
| [deleted]
| 12ian34 wrote:
| Nice website, but I wouldn't switch to this from Fish/Zsh on
| account of:
|
| 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).
| pclark wrote:
| #2 is really quite absurd - especially here of all places - how
| do you decide if a product or service will never "sell out"?
| jokethrowaway wrote:
| I generally try to avoid startups and either go for
| established companies (business offers are more likely to
| stay there and work as expected) or small bootstrapped
| business (cheap, more likely to stay true to their roots, do
| one thing well without breaking everything in the future).
|
| Startups are good for free trials as they have VC money to
| spend or finished deals (purchase once, consume once, forget
| about them).
| 12ian34 wrote:
| Absurd? I'm definitely more confident that Fish/Zsh will stay
| free forever without changing their incentives, licensing and
| pricing than a YC-backed startup whose primary goal is to
| make money.
| nerdponx wrote:
| #1 I do not agree with. This is a great idea for a tool, and I
| am willing to pay for it. This is an extension to my terminal
| and a useful adjunct to my shell, not a replacement for either.
|
| #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.
| cerved wrote:
| #5 is crucial, I highly value cross platform comparability.
| The existing differences are annoying enough as it is
| jrm4 wrote:
| I have found "it's open source" to be a real-life
| _meaningless_ response to "I prefer tools that I am likely
| able to have a significant amount of autonomous control over
| in the future."
|
| 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.
| 12ian34 wrote:
| #1 That's fair. Each to their own. For me I wouldn't be
| willing to pay even PS1 a year for it.
|
| #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).
| mschrage wrote:
| 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.
| tasuki wrote:
| > Linux is definitely not an after thought to us!
|
| Care to share more about this? Which terminals are you
| planning to support?
| sidlls wrote:
| The correct balance is 0% of terminal activity is sent with
| telemetry, unless the user explicitly and specifically
| authorizes it.
| mschrage wrote:
| Just to clarify, the text you type into the terminal NEVER
| leaves your device. Fig does not store or collect this
| information.
|
| 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.
| ljm wrote:
| > generate the suggestions to know which commands to
| prioritize
|
| 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?
| smoldesu wrote:
| So wait a second, the text I type into the terminal never
| leaves my device, but the commands I invoke do? What's
| the difference?
| rabidrat wrote:
| Yeah just don't accidentally paste your password into a
| terminal and press Enter.
| mbreese wrote:
| _> 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_
|
| 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.
| smoldesu wrote:
| +1 for this. I don't wanna be rude, but dataops isn't a
| joke: I'm not going to put my security into the hands of
| someone who already made egregious security oversights an
| integral part of their product.
| sidlls wrote:
| A distinction without difference, in my opinion. And it
| doesn't change the fact that anything other than 0%
| telemetry without full, complete disclosure _and
| permission_ from the user is not good.
| dheera wrote:
| Just add "0.0.0.0 fig.io" (or whatever it is, wireshark it
| to find out) to your /etc/hosts
| Cyberdog wrote:
| > I have a background in Swift development.
|
| Then why on earth did you go out of the way to implement this
| in JavaScript instead?
| mschrage wrote:
| The current implementation of Fig is a native macOS app
| (Swift/ObjC) that exposes an API to access terminal
| specific information - edit buffer, working directory,
| current process, etc. On every platform we support, we'll
| implement this natively.
|
| 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]
| verdverm wrote:
| 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)
| ljm wrote:
| I agree, and since it's VC backed it also feels like this is
| going to end up as SaaS for your terminal.
|
| 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.
| paulgb wrote:
| > 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?
| verdverm wrote:
| Probably a little of both.
|
| 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.
| nerdponx wrote:
| Have there been any attacks that are able to exploit
| iTerm shell integrations or similar tooling?
| verdverm wrote:
| ITerm has had security issues, yes, but that is besides
| the point.
|
| 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?
| brendanfalk wrote:
| > 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.
|
| > 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?
| verdverm wrote:
| To start with, remove network related code. There is no
| reason for a autocomplete language to need to fetch a
| file or send telemetry. A telemetry setting is
| insufficient
| zzyzxd wrote:
| > 1. Cannot identify any killer features above what I already
| have with forever free tools with much larger support
| communities.
|
| 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.
| zumu wrote:
| > 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.
|
| 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?
| dvt wrote:
| Just adding, from their website:
|
| > 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.
| Grustaf wrote:
| I mean, I agree, why is a cli tool YC backed, sure. But
| "several million dollars" is literally nothing in the VC
| space.
| ttt0 wrote:
| With millions of dollars you could probably just write a
| shell that does this sort of completion inside the
| terminal.
| [deleted]
| hnlmorg wrote:
| I did exactly that for free ;)
| Hammershaft wrote:
| Can we check it out! :D
| hnlmorg wrote:
| Sure, I'd love any and all feedback:
| https://github.com/lmorg/murex
| ttt0 wrote:
| Cool! Was it a one man project, and if so then how long
| did it took to get it to a reasonably functional state?
| hnlmorg wrote:
| It's about 6(ish) years old and went through various
| states of reinvention before I landed on the current
| design and it's been my primary shell for the last 4
| years now.
| f6v wrote:
| > 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'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.
| dheera wrote:
| > There's probably more money than people know what to do
| with.
|
| 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.
| meowkit wrote:
| Eh money is trying to park itself somewhere.
|
| Maybe the founders sold this as a way to get dev telemetry
| data + a subscription.
| [deleted]
| H8crilA wrote:
| Yeah but if there's dev telemetry involved it's a no-go
| from me. Definitely a no-go, the terminal is sensitive.
| arcturus17 wrote:
| WTF indeed.
|
| 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...
| smoldesu wrote:
| It strikes me as a pretty disgusting waste of "millions of
| dollars" to develop a Mac-exclusive app that does the same
| thing that your shell does, but slower.
| samblr wrote:
| I just wanted be a fly on the wall when Fig founders were
| pitching to these investors on how they are gonna make
| money.
|
| 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.
| azinman2 wrote:
| That's one theoretical way to make money, except not only
| do few companies do this now, but few devs would accept
| that.
|
| There are other ways to support developers thru honest
| tooling (eg IntelliJ).
| qbasic_forever wrote:
| Your employer's group policy controls, management agents,
| etc. that control access to their internal network can
| (and are) already telling them all of that information.
| They're basically rootkits that run anything they want on
| computers that access their network. Usually they just
| distribute certs, keys, etc. or remotely wipe a
| lost/stolen machine, but the capability is there to do
| anything.
| fnord77 wrote:
| pretty dystopian
| [deleted]
| mschrage wrote:
| > Is the VC backing for another product and the CLI tool is
| just a PR thing?
|
| 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
| design-material wrote:
| Why the fuck do you need my WORK email address with 2FA
| verification?
| hwn65 wrote:
| Great. Looking forward to the Terminal App Store and
| learning why my company should pay you for the arcane
| knowledge of where bash_completion.d scripts go. Let me
| guess, a lot of emoji involved?
|
| 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?
| zumu wrote:
| > We will never sell data. That just isn't the business we
| want to build
|
| 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?
| qzw wrote:
| No offense, but the only way I'll believe a company will
| "never sell data" is if it never collects any in the first
| place. Even if I have ultimate trust in the current
| founders, what happens if/when you're acquired or the
| investors install different management?
| lasfter wrote:
| > We will never sell data. That just isn't the business we
| want to build
|
| 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.
| qzw wrote:
| Good points. I'll add that the "disclosure by ransomware"
| risk is definitely not just theoretical anymore.
| saklani wrote:
| The product looks cool at least from the video.
| version_five wrote:
| CLI is a relatively "pristine" environment, where a lot of
| people's time is spent and nothing competes for our attention
| (or data as was pointed out). Any business model that could
| plausibly exploit this environment for financial gain would
| be an easy sell to investors.
|
| 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.
| Grustaf wrote:
| Well, it's even easier to imagine that they will start
| charging money for it. If it makes life easier for
| developers they can easily charge 20 bucks a month for it.
| heavyset_go wrote:
| > _once you start getting permission to pop something up in
| someone 's terminal window._
|
| Canonical already does this.
| heavyset_go wrote:
| > _Like why is a CLI tool VC backed? Is the business model
| just selling our data?_
|
| 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.
| avinassh wrote:
| Can you suggest some tools which auto suggest like Fig and work
| with zsh? The built in auto complete in zsh works nicely, but
| how do I get the drop down of all options?
| FractalHQ wrote:
| I really like Navi
| skratlo wrote:
| Fish does that by default
| lobocinza wrote:
| You need no tool at all as you can do I reverse search in any
| shell with ^R. If you want to do it with a better UX you can
| use fzf. If you want the suggestions you can use zsh-
| autosuggestions or fish shell. Setting them up is
| straightforward. And if you want an example config for Zsh
| you can look mine. Zinit, the package manager, automatically
| load/install the plugins when loading the shell.
|
| https://github.com/danisztls/dotfiles/blob/main/shell/zshrc
| elteto wrote:
| Maybe https://github.com/junegunn/fzf
| kubami wrote:
| Each needs to define an autocomplete script. oh-my-zsh
| provides plugins that do that for common tools like git.
|
| Those scripts are usually supplied by the CLI tool itself.
| For example for terraform: https://www.terraform.io/docs/cli/
| commands/index.html#shell-...
| vishnugupta wrote:
| This is the closest I see: https://github.com/ohmyzsh/ohmyzsh
|
| 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>"
| ttt0 wrote:
| ohmyzsh is a plugin manager for zsh, not a different shell.
| lobocinza wrote:
| https://github.com/zsh-users/zsh-autosuggestions
| rkeene2 wrote:
| Point #4 is particularly salient since it seems like telemetry
| information for a CLI-based tool which monitors the user's
| keystrokes doesn't provide the user any advantages.
| colonelpopcorn wrote:
| You can stop at #1. Why do I need this when oh-my-zsh exists?
| nerdponx wrote:
| They are totally different things. This is like asking why
| you need a computer at home when you already get the
| newspaper delivered every morning.
| Blahah wrote:
| It's the other way around. Why buy this newspaper when I
| already have a computer?
| nerdponx wrote:
| Ok, sure. The analogy is silly anyway, but silly
| arguments beget silly analogies.
| Exuma wrote:
| which oh-my-zsh plugins do you use that can do this? Is there
| an all-encompassing one or do you need to download tons of
| different ones like a docker plugin, git plugin, etc
| kubami wrote:
| But I think it will be the same with Fig. They will take
| the autocomplete scripts from the vendors and integrate
| them with Fig.
| mjochim wrote:
| I've been using grml's zsh config [1] for years. It's one
| file, I've never installed a single plugin, and it's been
| doing a lot. Couple of examples:
|
| - 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/
| quickthrower2 wrote:
| As soon as I saw the title I anticipated the Dropbox
| conversation!
|
| 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
| stakkur wrote:
| You summarized my exact feelings about it, especially #1, 4,
| and 5. I get the feeling that the team hasn't done their
| homework on potential users and existing solutions.
| mwcampbell wrote:
| No, I think it's incumbent on us developers to be more
| willing to pay for things. We know now that free doesn't
| really work.
| shaicoleman wrote:
| I'm willing to pay if it's on hacker friendly terms, e.g.
| something similar to the Sublime Text model:
|
| * 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
| Kudos wrote:
| Virtually the entirety of my desktop stack and dev tools
| are OSS. Can you clarify what you mean by "does not work"
| here?
| Hammershaft wrote:
| Free doesn't really work? What do you think about linux,
| git, emacs, blender, vulkan, etc?
| thesuperbigfrog wrote:
| >> it's incumbent on us developers to be more willing to
| pay for things.
|
| 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.
| michaelpb wrote:
| Yeah this project totally completely baffled me.
| "Autocomplete for the Terminal". What?? Bash has had
| fully programmable auto-completion for over 20 years [1]
| -- and that's just one comparitively bare-bones shell,
| out of dozens that are all free forever and not spyware.
|
| 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
| bloopernova wrote:
| It feels like the devs are completely clueless about open
| source, command line, and modern shell features.
|
| There's so many great projects for bash and zsh add-ons
| like fzf.
| smoldesu wrote:
| Here's a tip to anyone developing something like this: MacOS
| exclusivity will drive developers away from your program.
| nwienert wrote:
| I want to throw out something I had thought about while deep
| (deep) into fixing a broken server yesterday and having had a few
| thousand tabs opened over the course of 24 hours searching for
| every possible Linux command under the sun.
|
| 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.
| swyx wrote:
| sounds awesome, but seems very dependent on the app? for example
| I use hyper.is as my terminal, I've installed Fig but it doesnt
| seem to work? does this app only work on the default mac
| terminal?
| brendanfalk wrote:
| Our server also crashed when we first posted this.
|
| Try running `fig update` in your terminal. This will download
| the most up to date version of Fig's completion specs
| swyx wrote:
| ah ok so you got hugged to death, nice.
|
| but... why is Fig phoning home to your servers when i'm
| typing? what's local and what's not? this is alarming. does
| it go down if i am offline or have "lie-fi"?
| mschrage wrote:
| Fig does not "phone home" when you type!
|
| 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.
| mschrage wrote:
| 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)
| swyx wrote:
| it works now and works in other terminals, thank you. see
| other response for my alarm...
| xenodium wrote:
| Neat! A bit ago, I wanted something similar, so I glued company
| and pcomplete in an Emacs eshell https://xenodium.com/eshell-
| pcomplete-company-completion
| lasfter wrote:
| I detest that it has become normalized to grant tech companies
| access to personal data with only limp promises that it won't be
| misused.
|
| 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.
| fabiospampinato wrote:
| This is cool, is the idea to eventually develop a full-blown
| terminal too?
|
| That seems where most of the value is to me, like you can't just
| make a 10x car by attaching stickers to an existing one,
| eventually you are going to need to redesign the whole thing, the
| same is probably true for terminals too.
| brendanfalk wrote:
| Thanks so much!
|
| Yes - we would love to build our own terminal one day. I agree,
| a first party experience will make Fig much better. We think a
| good terminal needs to be fast, cross platform, customisable,
| and extendable (this is easier said than done).
|
| That said, one day we hope to build team-based tools too.
| Developers like to choose their tools - we would love to make
| Fig work, even if you weren't using a Fig terminal. We likely
| will also do the hard work of integrating with the existing
| terminals. You choose your tools and Fig is an integration on
| top.
|
| If you're interested, here are some of the things we plan on
| expanding into. https://fig.io/videos/old-sizzle-reel.mp4
| version_five wrote:
| This video was helpful to see. I do like the idea of being
| able to enter arguments in a form and get the full command,
| especially for complex scripts. An obvious extension would be
| pulling out argparse info e.g. from python scripts and
| letting the user enter arguments via a form
| brendanfalk wrote:
| > An obvious extension would be pulling out argparse
|
| Yes absolutely. A lot of possibility. We hope to create a
| whole new way of building terminal apps!
| forgotpwd16 wrote:
| That's nice but, seeing it's backed up by investors, what's the
| monetization plan for this? I don't think people will pay for
| support for such a tool so selling binaries or extra features to
| paying customers?
| dheera wrote:
| I've been using xonsh, which also has autocomplete for a lot of
| things, and I LOVE the python shell because bash syntax is very
| alien to me.
|
| The screenshots of fig look awesome, especially the git syntax
| and things, but my main feedback is I can't figure out what the
| hell fig is.
|
| > git clone
| https://github.com/YOUR_GITHUB_USERNAME/autocomplete.git fig-
| autocomplete
|
| > npm install
|
| First reaction is WTF? I thought Fig was going to be some bash
| replacement that does autocomplete and was hoping to ask for a
| matching xonsh replacement.
|
| But why do I need my git username and npm to have autocomplete in
| the shell?
| mschrage wrote:
| To get autocomplete working, you just need to install the macOS
| app. (https://fig.io/hn)
|
| These instructions only apply if you want to develop your own
| completion specs and are setting up the dev environment!
| dheera wrote:
| Oh I see. I use Linux, so I guess this isn't an option.
| skyfaller wrote:
| I think it's worth mentioning tldr as an effort towards more
| readable man pages: https://github.com/tldr-pages/tldr
|
| Personally I like tealdeer for a tldr client b/c it's written in
| Rust and I think the name is fun, but the other tldr clients I've
| tried all seem fine as well: https://github.com/dbrgn/tealdeer
|
| tldr doesn't do autocomplete, but between fish shell's
| autocomplete and tldr I feel I'm able to figure out most simple
| commands in the terminal.
| crazypython wrote:
| This is misleading. Fig's completions data files are open-source,
| but the completion engine that runs the completions is completely
| proprietary.
|
| 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.
| forgotpwd16 wrote:
| >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.
| lykahb wrote:
| The fuzzy completion tool fzf and a handful of zsh plugins cover
| all my needs.
| throwawayboise wrote:
| Judging from the other comments I'm in the minority here, but I
| use the command line precisely to avoid this kind of pop-up
| distracting stuff. I'm one of those programmers who disables
| intellisense, etc. as much as I can.
| jlg23 wrote:
| I've been a unix user for more than 2 decades now and have seen
| many of projects like these. And I've dismissed all for the
| simple reason that they don't fix the problem at its roots:
| getopt et al should be instrumented to provide valid completions
| for all unix commands. A layer on top is destined to be out of
| sync with the actual implementations soon. We only get one more
| level of indirection, one more abstraction layer that can go
| wrong. I simply don't get it.
| mschrage wrote:
| Totally agree! The closer autocompletion lives to the source
| code, the better.
|
| 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...]
| alexadelman wrote:
| Congrats on the launch!
| u9rptDjqLl0Pdcz wrote:
| What is the business model? Is this going to be a paid tool when
| out of beta?
| mschrage wrote:
| Autocomplete will always be free for individuals. We plan on
| charging for team-based collaboration, like private completion
| specs for internal scripts and CLI tools.
| f6v wrote:
| Is this the kind of startup that competes with git shortcuts? I
| can replace "git push origin master" with "git pom"...
| qwertox wrote:
| Does this work on mintty (cygwin)?
| mschrage wrote:
| Currently, Fig only supports macOS.
| nikolay wrote:
| I am disappointed. I've been on your waiting list, you told us to
| watch for HN announcement, and it's still walled.
| mschrage wrote:
| Did you use this link: https://fig.io/hn ?
|
| Let me know if you still can't get access. matt [at] fig.io
| d--b wrote:
| I mean no offense this is really appealing to me, but how are you
| going to monetize this?
| klinskyc wrote:
| Presumably charge companies per-seat for their engineers to use
| it?
| mschrage wrote:
| 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.
| d--b wrote:
| Sorry didn't see that. On a side note: I deleted the app when
| it asked me for my email. Good luck.
| sdevonoes wrote:
| Serious question: why didn't you just give a fake or
| temporary email address? That's what I do all the time.
| d--b wrote:
| They go as far as asking to validate the email with a
| code... That plus the fact that they do send data to
| their servers for some reason...
| MattGaiser wrote:
| Do you consider your email to be all that private?
| dannyw wrote:
| In the context of an app that requests accessibility
| access (read: everything I do on my computer, without
| restriction), absolutely!
| yjftsjthsd-h wrote:
| But if it has that, isn't your email address almost an
| afterthought? I mean, if I can keylog you, who cares
| about your email address?
| soperj wrote:
| I have a real fake email address for this. It's been
| compromised in a bunch of leaks, my real email address
| has never been. I also get way less spam in my real
| email.
| [deleted]
| momento wrote:
| Personally I am not a huge fan of asking for an email
| address at the end of a installation process.
|
| 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.
| mschrage wrote:
| This makes sense. Thank you for the feedback! :)
| pandemic_region wrote:
| > We plan to monetize by supporting autocomplete for companies'
| custom scripts and internal CLI tools.
| rolandtshen wrote:
| Been using Fig for a few months now, and really can't see myself
| living without autocomplete for git branches and npm packages
| vrtcn wrote:
| Highly dubious... asking for access to control the computer,
| asking for email, communicating with their servers. I don't care
| how much time this would save me, it absolutely isn't worth the
| risk.
| growt wrote:
| I have just one question: will this work over ssh? So when I run
| this on my Mac to do a git commit via ssh on a server, will
| autocompletion work?
| brendanfalk wrote:
| Yes it will!
|
| See this example:
| https://fig.io/images/slideshow/screenshots/ssh.png
|
| It should work out of the box, but you may have some issues if
| you have multiple SSH connections to the same remote machine or
| if your remote machine uses an async prompt (like
| powerlevel10k).
|
| If you have any issues, feel free to email me and I'll help get
| you set up brendan AT fig DOT io
| billiam wrote:
| Can I pay you money for this awesome product so I don't feel bad
| about opting out of your telemetry? What's fair? I think a lot of
| us would do this voluntarily. Your privacy disclosure is great--I
| just don't want to be the product on principle.
| dannyw wrote:
| You shouldn't feel bad for opting out of telemetry!
| mschrage wrote:
| 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
| :)
| adkadskhj wrote:
| Fwiw, i won't be using this because i can't buy it. I don't
| use any dev software that's not either FOSS or purchasable.
| Over the years i've suffered enough at the hands of
| changing monetization strategies that it's just viewed as
| risk for me.
|
| 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.
| Closi wrote:
| I get this - it's the whole "if you aren't the consumer
| you are the product" piece.
|
| 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?
| mxstbr wrote:
| I've been using Fig for months now and it's become a must-have on
| my machine. I particularly love the git branch, npm package and
| yarn command autocompletion -- my previous zsh plugin didn't have
| those and I use them all day every day.
|
| Disclaimer: I invested in Fig recently because I'm such a fan.[0]
|
| [0]: https://mxstbr.com/investing
| fortran77 wrote:
| I find autocomplete for commands to be, sometimes, a little
| dangerous. I'd at least turn it off when root or sudo....
|
| PowerShell does a good job with autocomplete on commands and
| options --if you're using PowerShell of course. Fortunately, it's
| cross platform.
|
| https://docs.microsoft.com/en-us/powershell/scripting/window...
| mschrage wrote:
| For 'dangerous' commands, Fig requires you to press enter twice
| - once to select suggestion and insert it into the terminal and
| then again to execute it!
| fortran77 wrote:
| Well, that's a good idea!
| klinskyc wrote:
| Congrats on the launch! Exciting to see all the progress
| djrogers wrote:
| 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.
| GordonS wrote:
| 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.
| mschrage wrote:
| 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.
| GordonS wrote:
| > 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.
|
| 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!)
| mschrage wrote:
| No worries. We determine who is on your 'team' based on
| email domain excluding webmail domains, like gmail.com
| and hey.com.
|
| 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!
| GordonS wrote:
| Ah, then it finally clicks. I really think you need to
| make this a lot clearer though. As others have already
| pointed out, if you're going to require this information,
| I think you need to ask for it up-front - don't ask for
| it at the end of the installer.
|
| 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.
| betareduce wrote:
| Is < 50ms considered fast? I recently tried out xterm and I felt
| the decreased latency compared to my current alacrity setup. I'd
| love a modern terminal that's fast too
| vhanda wrote:
| This seems really amazing. Please excuse my paranoia. Your
| privacy policy is very well written and easy to read. That's
| rare.
|
| 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)
| brendanfalk wrote:
| 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
| dannyw wrote:
| I think you should reconsider daily pinging still taking
| place when the user explicitly asks to disable telemetry.
| laurent123456 wrote:
| Telemetry being on by default on something like this is going
| to be hard to pull off. Homebrew has telemetry but it's only
| for Homebrew commands. This would potentially be for every
| single command one type in a terminal. It just takes one
| little bug in the app and who knows what can be sent, maybe
| passwords and so on.
| yjftsjthsd-h wrote:
| > Homebrew has telemetry but it's only for Homebrew
| commands.
|
| It was also more than a little controversial.
| smoldesu wrote:
| Homebrew's telemetry burned so many bridges back in the
| day. I had a friend who sold his week-old 15-inch MBP
| over that.
| sidlls wrote:
| And why I don't use the tool.
| tofuahdude wrote:
| Disable except for once a day is not actually disabling.
| That's pretty whack.
| brainfish wrote:
| 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.
| vletal wrote:
| So what does it do? Is it just about the daily ping?
| calrueb wrote:
| I assume they use it to track DAUs/MAUs. Otherwise, they
| only have data on installs, but wouldn't have visibility
| into user retention.
| qzw wrote:
| Yes, most likely. Being VC backed means they will want to
| be able to show pretty growth charts every few months.
| brendanfalk wrote:
| I hear you and I agree. This is a huge oversight on our
| part and we will make the disableTelemetry command turn off
| all telemetry. This will come out in our next build
| kokanee wrote:
| Nice! Good call. These HN posts can bring a lot of heat
| but it comes with extremely valuable feedback like this.
| For me it's too late; I've now seen that you need to be
| caught in the act before you'll do the right thing -- but
| for folks who didn't see this you'll be much better off
| going forward.
| binbag wrote:
| This seems really harsh. It's not like the guy tried to
| hide from you that it would still permit one daily ping.
| He told you straight up.
| isitdopamine wrote:
| Please make telemetry opt in, not opt out. And please honor
| the disableTelemetry setting by disabling the ping.
| yur3i__ wrote:
| Telemetry by default in terminal autocompletion is a pretty
| big turnoff for me, even if it can be disabled
| electroly wrote:
| I can't imagine that daily ping being worth the loss of trust
| from having a "disable telemetry" setting that doesn't really
| disable all telemetry. People who care about disabling
| telemetry will care about the daily ping, too.
| bredren wrote:
| If this is a real concern, I recommend Little Snitch or
| similar. Many apps do not offer any way to turn off various
| pings.
| hnarn wrote:
| > Please excuse my paranoia.
|
| Expecting your _terminal_ to have a default setting to _not_
| call home is not paranoia: it 's absolute common sense.
| [deleted]
| muhammadusman wrote:
| Nice onboarding but I don't like the email requirement.
| Ramiro wrote:
| Fig's integration for Makefiles makes my life so much easier!
|
| I've played with shell autocompletion before, but this way easier
| to use. Good luck!
| mschrage wrote:
| Thanks Ramiro! Glad to hear you're finding Fig useful :)
| CJefferson wrote:
| What does "Sensitive data is never tracked" mean? I can't find
| any more details, and is like to know exactly what on the
| terminal is considered non-sensitive?
| brendanfalk wrote:
| We consider most things you type in your terminal to be
| "sensitive". Fig only ever tracks the root command for any
| completion you do. For instance, if you type `git push origin
| master` and complete on `master`, Fig will only ever see `git`
|
| You can see our full privacy policy here:
| https://fig.io/privacy
| throwawaybutwhy wrote:
| $ /home/throwawaybutwhy/miscellanea/world_domination_plan_no_
| 1.sh --help
|
| You will see my login name, the structure of my folders and
| my intent to take over the world. Kinda sensitive, it seems.
| mschrage wrote:
| haha :) We actually send the name of the completion spec
| rather the initial token. In this case, it would be
| "dotslash".
| phowat wrote:
| 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 !
| brendanfalk wrote:
| 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!
| admissionsguy wrote:
| How did a startup with such an obvious idea get started in 2020?
|
| 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.
| mschrage wrote:
| I honestly feel the same way. Once you use Fig, it feels like
| such an obvious idea. It didn't require new APIs or anything
| like that.
|
| 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.
| andrewmcwatters wrote:
| Is Fig patenting this? How does the company prevent itself from
| being f.lux'd?
| mschrage wrote:
| Autocomplete is just our first product. We've built an API that
| makes it possible to add visual extensions to any terminal.
|
| We want to expand into stuff like runbooks, UIs for deployment,
| internal infra, etc..
| andrewmcwatters wrote:
| I wish you the best. It's a nice product.
| Jakobeha wrote:
| Setup is very smooth. I'm impressed how well this integrates with
| my macOS. Also a bit suspicious, but unless/until there's real
| evidence, honestly I think it's just because of VS funding + how
| well the setup / integration went.
|
| Linux and especially smaller Unixes is where tools like this are
| really useful. My experience with Linux is that most stuff has to
| be installed on the command-line, or if there is a GUI it's
| clunky and/or missing features. And I would consider myself
| moderately experienced with the macOS Terminal, but I often got
| stuck / slow with Linux.
|
| I really hope they add support for IntelliJ and other integrated
| Terminals. I'm pretty sure I end up using those a lot more than
| standalones.
| mschrage wrote:
| Thanks! We currently work with the VSCode integrated terminal
| and will add support for Jetbrains IDEs, if possible!
| albertzeyer wrote:
| There are many related attempts to make the terminal more modern,
| by including some HTML in it, improved auto-completion, and many
| other ideas.
|
| 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.
| mschrage wrote:
| These are all such cool projects. We took some early
| inspiration from TermKit! I think the tricky thing is that you
| need to switch terminal emulators in order to use the new
| features.
|
| 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.
| tibbon wrote:
| This is pretty cool!
|
| I've only poked with it for a few minutes on a spare laptop I use
| for vetting software, but I did notice that the Kubernetes
| autocomplete only goes halfway, at least in iTerm.
|
| If I do `kubectl top` it doesn't recommend `kubectl top
| pods|resources` in the autocomplete. Autocomplete needs to work
| for the whole line, not just the first argument.
| mschrage wrote:
| It looks like this is an issue with the completion spec for
| kubectl[0]! I'm not super familiar with k8s, so you wanted to
| help fix this (eg. writing the generator to list pods) that
| would be amazing! <3
|
| [0]https://github.com/withfig/autocomplete/blob/2a0eea63d04f6b2
| ...
| dipoAreoye wrote:
| God bless yall, this was so needed
| brendanfalk wrote:
| Glad you're liking it!
| MattGaiser wrote:
| I got tripped up on your Tips for Troubleshooting page. I tried
| validating install at that point. But otherwise this seems great.
| Hope you guys plan a Windows version too.
|
| Happy to be one of the first 1000 devs that you personally get to
| know.
| brendanfalk wrote:
| Hey everyone - I'm Brendan, one of the other co-founders of Fig.
|
| Our server endpoint to download all of Fig's specs just went
| down. We are fixing this right now. Apologies for the hiccup!
| Will let you know when it's back up.
|
| *Update*
|
| Our server is back up. If you downloaded Fig and it isn't
| working, please run `fig update`
| jgrimm wrote:
| Just tried this at university and interestingly all fig
| functionality is blocked when using the university's wifi,
| probably due to the proxies they have in place, while hot-
| spotting from my phone over 4g seems to work fine.
|
| 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
| mschrage wrote:
| 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!
| ionwake wrote:
| DOes anyone know if this works with hyper.js?
| esilverman wrote:
| Can I use the autocomplete without the side bar on the side of my
| terminal?
| brendanfalk wrote:
| Yes! Sidebar was a legacy feature. This is disabled by default
| for new users. We actually just removed the toggle to turn it
| on/off from our menu
|
| Running `defaults write com.mschrage.fig sidebar hidden` should
| make it disappear.
| nathancahill wrote:
| 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<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
|
| (btw, broken link at the bottom of this page:
| https://fig.io/docs/getting-started -
| https://fig.io/concepts/dynamic-suggestions should be
| https://fig.io/docs/concepts/dynamic-suggestions)
| mschrage wrote:
| 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.
| verdverm wrote:
| Many CLI libraries provide the ability to generate auto-
| completion scripts. Cobra for Golang is an excellent example.
| It provides functions for all the major shells and is quite
| simple to add to any Go CLI using the library. It also
| supports dynamic calls for when someone wants to autocomplete
| on a resource known only to the running CLI.
|
| For python argparse, there is argcomplete in the same vein
| mschrage wrote:
| We're building out integrations with CLI libraries like
| cobra and oclif[0], so you can generate a Fig completion
| spec automatically the same way!
|
| Then it just comes down to the Fig popover UX.
|
| [0] https://github.com/withfig/oclif-plugin
| verdverm wrote:
| Does Fig then need to mirror autocomplete for any command
| which wants to make use of the popover UX?
|
| (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)
| spockz wrote:
| So the added benefit of Fig over completion provided by zsh/fish
| together with say Cobra is the "slick" ui and the (community?)
| sourced completion based on man pages etc without the apps
| themselves having to provide completion data?
|
| I'm having quite some trouble understanding why I would add a
| tool that potentially sends all my terminal to the web...
___________________________________________________________________
(page generated 2021-05-25 23:00 UTC)