Generally, a destructive shell command prompts for approval. But I suppose overfumbly fingers could still cause grief.
Type/command aware tooling is a night and day difference.
Generally, a destructive shell command prompts for approval. But I suppose overfumbly fingers could still cause grief.
Type/command aware tooling is a night and day difference.
I feel like I've trashed millions of files I shouldn't have with `rm` and trying to be clever with regular expressions.
I've done this enough times I use `ls` first, then `rm`
Yeah, I generally will use `find . -name "<my pattern"` nowadays, just so I can see all the potentially recursive files as well, and then when I'm 100% sure that what I'm doing is good, I will pipe that into xargs or parallel.
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.
Exactly, which is why we check for ourselves instead of expecting it to hold our hand.
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.
I mostly agree, but sometimes I wish that `rm` would have default to "confirm before destroying", and add a flag like `-y` to not prompt, more or less like how `apt` works on Ubuntu.
That's actually a way better experience than no confirmation and confirming each item individually.
Note: Normal shells use glob(7) expressions, not regular expressions.
You know I googled this immediately after I posted it, and you're absolutely right, but a good chunk of the syntax still kind of looks like regular expressions so I don't think I was too far off!
Generally? Do you have examples in mind? The ones I think of are destroy first and ask questions only if told to do so: mv cp rm redirection tee
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 <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.
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.
100ms is a long time to wait for each completion suggestion.
I was going to say the same thing. In what world is 100ms fast on a computer? (for something not making a network round trip)
The claim isn’t that 100ms is fast, it’s that the blame for the latency lies in the engineering, not the language.
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-...
It is very possible to write sub 100ms procedures in TS, […]
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...
This was the first thing I noticed, too. Why TypeScript? Is it: a) efficient enough, esp. compared to a Bash/Zsh/PWSH alternative, that spawning a JS interpreter for each autocomplete is no biggie? Is b) TypeScript just much more efficient than I thought? Or c) is TypeScript Microsoft's hammer, and everything looks like a nail?
I tend to think since VSCode plugins are javascript all new tooling from Microsoft seems to be written in typescript. As a non front end dev though `npm install` is an instant turnoff for me.
I agree. I was going to install and backed out when I saw `npm install` as well. I am wondering if my priors need to be updated, though (namely: JavaScript is slow, inefficient, and unsuited for anything outside of webdev).
I think javascript is plenty fast these days. My only problem with Typescript/Javascipt is the toolchain is very complex/confusing to someone on the outside. In my experience, Rust/Go or even python is easier to get into if you're not living it every day. Besides familiarity, I'm not sure why someone would choose Typescript for non-web work.
Ya, cool name, but worse privacy than gorilla, more awkward than llm.sh and why would I ever get the Microsoft version of something I can get elsewhere without the worry that I'm about to be devoured by a corporate anglerfish.
Did you check the page? It's MIT-licensed and isn't about GPT or text generation. It's Intellisense, for the shell.
then what makes it better than withfig/autocomplete?
That’s what it’s based on.
It is withfig/autocomplete. The only difference from their runtime is that this gives results directly in the console, instead of using a graphical overlay. I believe that means you could use this in an SSH session.
I downloaded fig, then immediately deleted it after it requested way too much access to my github account to even start. So... that's a big thing.
It's available for Linux and Windows.
This is cool.
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.
The world would have been a much better place if CLIs themselves defined strict interfaces using standard data structures.
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).
And we would also need an options that does CLI argument parsing only, and either returns an error related to parsing one or more options or "ok".
This could be used to do "form validation" of CLI args as they're typed in the shell.
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.
All we need is something that will tell us who is right and then impose that vision on everyone.
Like PowerShell?
1980s... but like 2020s-style.
Coming next: auto-complete for punch cards.
can you expand on this?
I think they meant "using the terminal (1980s)... but like 2020s-style (intellisense)"
Y'know, because it's not like tons of people use the terminal on a daily basis in the modern era. /s
Yeah, they claim because it's better but the reality is that they simply cannot build good cross-platform UIs on a budget / on time.
Could you please stop posting unsubstantive comments and flamebait? You've unfortunately been doing it repeatedly. It's not what this site is for, and destroys what it is for.
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.
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.
https://github.com/withfig/autocomplete is it this?
Looking at the main author's gorhub profile, they forker Fig's repo.
So I have to take a shell dependency on Node.js?
Hard pass
Maybe the users don’t care about their devices
Haha, I though the same...
npm install
NEXT!
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.
The implementation has obviously never been run on a Unix/Linux:
* 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
Inshellishit lol
It doesn't work on Windows either... at least by a comment in the issue. I don't have Windows.
It's pretty cool but still seems a little rough around the edges. My simple test case was to launch into the shell and see if it loaded any of my normal shell configs like highlighting or auto-suggestions (based on my history) but it seems to just be its own shell entirely. It also doesn't seem to play nicely with `zsh` since I tried to do a `..` (which is a common `zsh` alias for "cd .." which got a `zsh:1: permission denied: ..` and then I tried to run `cd ..` it did nothing.
Keen to see how this pans out though!
stock macos zsh's `..` just gave me 'zsh: permission denied: ..'
zsh 5.9 (x86_64-apple-darwin22.0)
Yep it's not stock `zsh` alias, so that suggests to me then that Inteshellisense isn't reading my shell config at all.
I'd be curious how this compares with Fish, which has autocomplete as well. It's worked fantastic for me so far. Once you have it, it's hard to go back!
This looks much cooler than fish autocompletes imo. But this replaces the nice fish stuff with `>` as a prompt, so I'll stick with fish.
The readme for this project states that it supports fish, does it replace the prompt?
The name is terrific.
First good name to ever come out of Microsoft. I'm sure it just barely succeeded over Visual Windows Subsystem for IntelliSense Core.
The fact that it's coming from Microsoft is even crazier, because obviously you know they had to go through clearance - and made it.
I half wonder if the author checked the name first, then started coding......
I use Fig which also has this and it seems to be better at it
This is using the same library as Fig for autocomplete, but cross -platform and without requiring an account.
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).
Knowing it is go I like it better already. Anything that does not require a runtime gets a head start in my book.
I get this error on zsh: Unsupported shell: '', supported shells: bash, powershell, pwsh, zsh, fish
You need to run it with the —shell flag and provide “zsh” as the value
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.
If using bash in vi mode instead of emacs mode: ESC v.
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-lineIs this fully local? I glanced around and didn't see any mention of chatgpt/gpt/codex so I'm thinking it is?
There is really not much code to speak of, and a quick perusal didn't yield anything sus. Initial guess is that it's not very efficient, but I really didn't look that closely.
I wish I had something like this without it replacing the shell prompt with `>`.
I'd guess you could source it and then override the PS1 env variable with whatever prompt formatting you wanted.
ok. can someone explain to me. I've been using ctrl+r for god knows how long and it solves all my shell completion needs.
is inshellisense for average users like me or more advanced users?
I use zsh plugin, autosuggests, and ctrl r, too.
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.
Starting to type "dir": "d[el /q /s .]" (press any key to accept)
Not up to the mark with https://github.com/marlonrichert/zsh-autocomplete which works contextually.
If you're interested in GPT-powered shell autocomplete, check out https://butterfi.sh
This also enables shell-aware LLM prompting!
i use warp's terminal and i love it, but I think im gonna love this more because its OSS
Is anyone else feeling off about typescript in the terminal emulator? I guess it's not worse than TCL or Perl.
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)
This looks awesome! Is the next step something like a Copilot integration?
There’s Copilot CLI coming soon[0] but I think something that autocompletes would feel more natural most of the time.
For those who haven't read the code:
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.
Fig.io with no account and calling home, count me in.
Thanks for everyone creating issues. I'm working on addressing all the issues and they'll be included in the next release.
Connecting NPM-powered software directly to my shell? Over my dead body.
Awesome! And it supports fish! Just the other day, I was wishing we had something like this.
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?