I built this terminal native runtime for Fig's autocomplete to support Windows and Linux. Would appreciate any feedback on it! |
I built this terminal native runtime for Fig's autocomplete to support Windows and Linux. Would appreciate any feedback on it! |
This also enables shell-aware LLM prompting!
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 <TAB> key for autocompletion.
Before I disabled this feature, I consistently experienced delays of over 300ms between triggering autocomplete and receiving the actual results. I must admit that this was on an Intel Core i7, so I assume the performance is much better with newer processors. However, even after more than two years without bash_completion.sh, I have already committed many command line tool flags to memory so I would only consider using a tool written in a compiled programming language that can provide autocomplete in 100ms or less, potentially requiring the inclusion of hardcoded information in the binary.
I wish those aboard the TS/JS hate-train knew what they were even complaining about.
Yes, and that's what people are complaining about. People use the wrod typescript in this thread because, well, it's what shows up on github, but the same argument would come up if it was in pure js.
People have problem with the fact that you are running a nodejs for the terminal enhancement, not what language it uses
I won’t dispute this statement since I currently lack the means to assess inshellisense. Would it be possible for you (or someone with a functional Node + NPM setup) to install inshellisense and share the actual performance figures? You could use a tool like hyperfine (https://github.com/sharkdp/hyperfine) for this purpose.
As an attempt to test this myself, I used a Docker image (version 21.1.0-bookworm from https://hub.docker.com/_/node/). The TypeScript tool installed without any issues, along with the binding, which simply adds the following line into ~/.bashrc:
[ -f ~/.inshellisense/key-bindings.bash ] && source ~/.inshellisense/key-bindings.bash
bash: /root/.inshellisense/key-bindings.bash: line 1: syntax error near unexpected token `$'{\r''
'ash: /root/.inshellisense/key-bindings.bash: line 1: `__inshellisense__() {
The version of Bash available in this Docker image is 5.2.15(1)-release.
I verified that the content of /root/.inshellisense/key-bindings.bash is exactly the same as https://github.com/microsoft/inshellisense/blob/main/shell/k...
I'm not some extreme purist that thinks everything should be made in C and then hand optimized in assembly, but Jesus, how wasteful can You get before the slightest amount of self awareness starts to kick in.
And for what reason, to save a week of engineering time learning GOlang?
From a quick peek, carapace-bin supports more shells (including and powering the one I use, nushell).
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)
is inshellisense for average users like me or more advanced users?
Ctrl r is okay and it is a very convenient if you already typed the command.
Inshellisense seems to help with knowing what subcommands, flags and file paths are available, and it even provides a small docs helper for the flags and commands.
If you didn't try these tools, I'd encourage you take a look, it helped me a lot, especially when I work with tools whose commands I don't know by heart or used a while ago.
Coming next: auto-complete for punch cards.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
This is latching on the to the word "Typescript" and immediately beginning the whining.
This thread is filled with a shitload of this knee jerk idiocy. If you want to promote Go, at least learn how to complain about factual things instead of writing some fiction and complaining about that. Node has legit issues you could complain about. FFS, whine better.
You should be able to fix it with:
vi $HOME/.inshellisense/key-bindings.zsh -c "set ff=unix" -c ":wq"Can you be more specific? Been a while since I installed it but I don't remember this part. It's not even listed as an "Authorized GitHub App"
https://www.nngroup.com/articles/response-times-3-important-...
Obviously this are different use-cases, but wouldn't be suprised if it was big enough for people to at least notice
I agree. I used to play a drum beat game with my daughter and son-in-law, who are both professional musicians, and they could hit beats within a 10ms window, while I struggled to get under 100ms.
But 100ms seems like a reasonable upper limit for autocomplete to me.
PS: My son-in-law is a professional drummer and can't play Rush YYZ on Rock Band (just had to include this tidbit cause it'll piss him off)
* 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
Type/command aware tooling is a night and day difference.
What is sad is that it has to rely on a library of completion specs. It shows what kind of stone age foundations we are building on top of. The world would have been a much better place if CLIs themselves defined strict interfaces using standard data structures. Not only for auto completion, also gives much more accurate error checking of bash scripts. Same goes for data piped in and out of command.
It would thoroughly dispense with the whole argument parsing routine in the first place, which could now be done in a standardised manner; arguments could be defined as strict types with possible values limited to a set, and best of all, they wouldn't just be a dictionary/hash-map of strings to strings—the arguments could actually be named variables with values, in the context of the called utility.
It would certainly be quite a powerful shell, and I'm sure something similar has already been done. I just can't think of an example..... A Powerful shell, running on some Common Language Runtime; I wonder what it could be.
Hard pass
> npm install
NEXT!
This reuses Fig.io's internal completion engine to actually get the job done.
Because of that, it forces the language choice of Typescript, and the heavy lift is done by Fig's engine.
I hope the OP continues with the work and improves it. I was looking forward to trying Fig on Linux. This sounds like a step towards that.
From there, :wq will drop the text back into your command line. If you have Copilot set up in either of those, then it will also work here.
I know from working on https://github.com/hiAndrewQuinn/shell-bling-ubuntu that Neovim's LazyVim setup now supports Copilot out of the box now. I never had much trouble setting up the Vim plugin either. YMMV.
zsh starts minimal, so one needs the following for such a feature to be operational:
# enable
autoload edit-command-line
zle -N edit-command-line
# bash-like emacs mode shortcut
bindkey "^X^E" edit-command-line
# bash-like vi mode shortcut
bindkey -M vicmd v edit-command-lineIt’s really cool to see alternative implementations of IDE-style autocomplete in the terminal. Nice work!
I half wonder if the author checked the name first, then started coding......
Keen to see how this pans out though!
zsh 5.9 (x86_64-apple-darwin22.0)
There’s Copilot CLI coming soon[0] but I think something that autocompletes would feel more natural most of the time.
Too bad…
Well it's not too late just yet.
How about if all CLI exes had an option, say --dump-cli-options, that wrote out a spec of the supported commands/flags/options?
Something like e.g. Python's argparse should be able to effortlessly spit out this info (and the same for other similar argument parsing libraries).
This could be used to do "form validation" of CLI args as they're typed in the shell.
'/tmp' will eventually be cleaned by the OS so no (prolonged) space worries.
My point was that I don't feel like Unix really stops you from doing destructive scary stuff. It seems like it's perfectly happy to let you break your machine.
Unixy tools tend do what you tell them, nothing more and nothing less. No confirmations, no output if successful, no progress bars, etc.
That's a feature in my mind, but I can see how it is easy to have your day ruined if you're expecting it to ask you again.
This was in the default when running in interactive shell for Mandrake Linux (way too many) years ago.
Last time I used the interactive option, it needed me to press Y once for every file.
If you have a list of 200 files you’re probably not even reading by the end.
“Globs do not include syntax for the Kleene star which allows multiple repetitions of the preceding part of the expression; thus they are not considered regular expressions, which can describe the full set of regular languages over any given finite alphabet.”
— <https://en.wikipedia.org/w/index.php?title=Glob_(programming...>
Microsoft gets lots of praise for maintaining Backwards Compatibility even if it's Bug Compatibility, yet POSIX gets shit for the same.
Perhaps ironically, if those programs asked me for each change I would just hold Y until it went away. Needing confirmation of each item is why I glaze over.