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?
I don't know how painful it would be, but I think I could adapt to a short delay of maybe 50-100ms where the shell won't respond to Return presses, only after accepting a completion. Just long enough ideally to make me re-read what I entered.
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.
To do this, you'd have to have some sort of common runtime, and nearly all command-line utilities would have to be compiled with said runtime, so that the parameters, names, and types of parameters for said utilities could be returned, parsed, and verified as a data structure, without having to manually parse the output of some `command --help` invocation.
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.
It's sad. If the world of software had better coordination and cooperation, we would be able to get so much more done. Instead we're constantly dumping and re-parsing the same data, re-implementing the same protocols and algorithms in dozens of different languages, each time with different quirks. Fixing the same bugs again and again.
I don't mind it, it's just another runtime that works on Linux and BSD. I have my neovim infected with extensions made in Node.js, Python, Lua, my weechat is infected with extensions made in Python, Perl, Node.js, and my zsh is infected with extensions with components made in Rust, C, and Python. Just make sure to pay attention to shell start times and RAM usage.
Alternatively, if you simply wish to occasionally bring Copilot into your shell, you should know that Ctrl+X Ctrl+E (on bash) / Alt+E (on fish) will open your current shell line up in $EDITOR, which you may set to Vim or Neovim.
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.
Fig autocomplete is really cool! With the Fig aquisition, what do you forsee happening to Fig's autocomplete offering in the long and short term? My impression is that Amazon was interested more in the other parts of your tech, with the scripts and automation capabilities.
Readit News
* 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
Dead Comment
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.
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.
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:
It’s really cool to see alternative implementations of IDE-style autocomplete in the terminal. Nice work!
Deleted Comment