6 ms·

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?

by gtf21 5y ago

deleted 5y ago
[deleted]
brendanfalk 5y ago
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).
- yogevyuval 5y ago
  What exactly do you mean by even when in SSH or docker?
  - brendanfalk 5y ago
    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 https://fig.io/images/slideshow/screenshots/ssh.png
    - krrrh 5y ago
      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.
    - evil-olive 5y ago
      I assume this is done by running 'ls' in the background and not showing the execution to the user, except as autocomplete suggestions? if I type 'sudo cp ' will it run 'sudo ls' to offer suggestions? this...is not good. my terminal should not be executing code on my behalf on remote servers I've SSHed to.
- gtf21 5y ago
  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 5y ago
    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 5y ago
  > 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 5y ago
    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
deleted 5y ago
[deleted]
dangom 5y ago
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.
- f6v 5y ago
  > if you walk into any research center or academic environment If they use their institution's infrastructure, it's managed by the dedicated system admins. No way they're going to allow this tool to be installed.
  - gspr 5y ago
    While I have exactly 0% belief in the success of Fig, and share a lot of the negative sentiment expressed in this thread, your parent post does make a point. I spent 10 years in the kind of academic setting described. A LARGE part of the work of the people in this example do their work on ordinary self-managed laptops without a sysadmin in sight (and probably very little common language in which to even begin communicating with a sysadmin, if they even know what a sysadmin is). The amount of time that is wasted by ordinary researchers being very uncomfortable with the terminal is staggering. Although I was/am a researcher in my own right, I do feel that I had an order of magnitude greater positive impact on research by helping out the approximate dozen of other researchers around me do their terminal and programming work more efficiently/better/smoothly/reliably. I definitely think there's huge room for improvement in this area. But I don't think something like Fig is the answer; safe and effective use of Fig seems to require enough wherewithal to ask someone (or google) how to set up bog standard autocompletion solution in the first place.
    - f6v 5y ago

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?

by gtf21 5y ago

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?

deleted 5y ago

[deleted]

brendanfalk 5y ago

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

yogevyuval 5y ago
What exactly do you mean by even when in SSH or docker?
- brendanfalk 5y ago
  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 https://fig.io/images/slideshow/screenshots/ssh.png
  - krrrh 5y ago
    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.
  - evil-olive 5y ago
    I assume this is done by running 'ls' in the background and not showing the execution to the user, except as autocomplete suggestions? if I type 'sudo cp ' will it run 'sudo ls' to offer suggestions? this...is not good. my terminal should not be executing code on my behalf on remote servers I've SSHed to.
gtf21 5y ago
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 5y ago
  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 5y ago
> 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 5y ago
  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

deleted 5y ago

[deleted]

dangom 5y ago

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.

f6v 5y ago
> if you walk into any research center or academic environment If they use their institution's infrastructure, it's managed by the dedicated system admins. No way they're going to allow this tool to be installed.
- gspr 5y ago
  While I have exactly 0% belief in the success of Fig, and share a lot of the negative sentiment expressed in this thread, your parent post does make a point. I spent 10 years in the kind of academic setting described. A LARGE part of the work of the people in this example do their work on ordinary self-managed laptops without a sysadmin in sight (and probably very little common language in which to even begin communicating with a sysadmin, if they even know what a sysadmin is). The amount of time that is wasted by ordinary researchers being very uncomfortable with the terminal is staggering. Although I was/am a researcher in my own right, I do feel that I had an order of magnitude greater positive impact on research by helping out the approximate dozen of other researchers around me do their terminal and programming work more efficiently/better/smoothly/reliably. I definitely think there's huge room for improvement in this area. But I don't think something like Fig is the answer; safe and effective use of Fig seems to require enough wherewithal to ask someone (or google) how to set up bog standard autocompletion solution in the first place.
  - f6v 5y ago