91–100 of 161 posts
Great idea! Also terrifying :) Given how often I accidentally commit the wrong text in vscode, I shudder to think of the damage I could do with this on my shell, hah! What safety measures are there/could there be?
A simple approach might be that if the resulting exit code is not 0 it won't be used to complete in the future.
I wish they had written inShellisense in a more efficient programming language than TypeScript. I recall disabling bash_completion.sh on my computer some time ago due to its negative impact on the startup speed of each iTerm2 session and the delay it introduced when using the key for autocompletion. Before I disabled this feature, I consistently experienced delays of over 300ms between triggering autocomplete and rec…
Don’t bring TypeScript into this. It is very possible to write sub 100ms procedures in TS, but an inelegant algorithm will be slow in any language, eventually.
Beyond the not-using-typescript for CLI tooling difference, it would be interesting for a comparison against carapace-bin, another shell agnostic completer: https://github.com/rsteube/carapace-bin (written in Go, since this thread includes other discussion about the choice of typescript for Inshellisense). From a quick peek, carapace-bin supports more shells (including and powering the one I use, nushell).
Co-founder of Fig here! Just want to say that I think this is awesome. It’s really cool to see alternative implementations of IDE-style autocomplete in the terminal. Nice work!
Btw if you don't mind me asking, how will Fig make money? Will it be integrations with stuff like AWS, GCP, etc.? Nice work on Fig!
Earlier quoted context omitted.
100ms is a long time to wait for each completion suggestion.
Jakob Nielsen says that 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result... https://www.nngroup.com/articles/response-times-3-important-...
Because otherwise requiring `npm` as a package manager for those of us who don't develop in either is silly.
(Yes, I know npm also implies JavaScript as a runtime environment, still nope)
Beyond the not-using-typescript for CLI tooling difference, it would be interesting for a comparison against carapace-bin, another shell agnostic completer: https://github.com/rsteube/carapace-bin (written in Go, since this thread includes other discussion about the choice of typescript for Inshellisense). From a quick peek, carapace-bin supports more shells (including and powering the one I use, nushell).
IDE style shell autocomplete for JavaScript or TypeScript programers Because otherwise requiring `npm` as a package manager for those of us who don't develop in either is silly. (Yes, I know npm also implies JavaScript as a runtime environment, still nope)
Co-founder of Fig here! Just want to say that I think this is awesome. It’s really cool to see alternative implementations of IDE-style autocomplete in the terminal. Nice work!
I'm pretty sure this is just a wrapper for Fig.
* shell config is created with CRLF https://github.com/microsoft/inshellisense/issues/8
* changing directory doesn't work https://github.com/microsoft/inshellisense/issues/5