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

It doesn't work on Windows either... at least by a comment in the issue. I don't have Windows.

Not up to the mark with https://github.com/marlonrichert/zsh-autocomplete which works contextually.

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.

A simple approach might be that if the resulting exit code is not 0 it won't be used to complete in the future.

That'd have the problem of tools like grep returning nothing, having an exit code of 1, but being a perfectly valid thing to suggest in the future.

When you're writing, building, and executing code, I would not expect a 0 exit code every time.

The fish approach

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

Yeah, you’re right. I was thinking of overly destructive commands eg. reformat etc.

I feel like I've trashed millions of files I shouldn't have with `rm` and trying to be clever with regular expressions.

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!

Regular expressions and glob(7) expressions look superficially similar, but it is mostly an illusion; they both use * and ? as common metacharacters, but both of those characters mean different things in the two systems. Only the [ and ] characters are used more similarly, but even those have their differences. The two syntaxes only have one common function which functions identically in the two systems, but it is invoked by different characters; specifically the ? (question mark) character in glob(7) exactly corresponds to the . (full stop) character in regular expressions.

To be pedantic: You're conflating the syntax of regular exprssions, with the (computer science) concept. Glob patterns are a kind of very resticted regular pexressions. Ksh extended the glob syntax so it has the full power of regular expressions in the computer science sense - though without all the extensions of modern regular expressions.

No, globs are not regular expressions.

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

You're right, normal globs are not regular expressions regardless of syntax. Parent is correct too, ksh globs are regular expressions. See shopt -s extglob in bash, setopt kshglob in zsh (extendedglob for zsh's native, IMO inferior, quantifier syntax).

I've done this enough times I use `ls` first, then `rm`

As much as I can, I do a 'mv ... /tmp' instead of 'rm -rf'. It gets the files out of the way, and provides a way out if that's not what I wanted.

'/tmp' will eventually be cleaned by the OS so no (prolonged) space worries.

/tmp is a RAM disk on many systems so be careful with very large files

To add to this, I've been a happy user of the trash-cli for forever. Can recommend.

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.

alias rm="rm -i" alias mv="mv -i"

This was in the default when running in interactive shell for Mandrake Linux (way too many) years ago.

That's actually a way better experience than no confirmation and confirming each item individually.

rm can do that... set an alias to ask to confirm every time.

That's fine on my computer, but if I'm logging into a server I'm not going to do that every time.

As much as we all wish it wouldn't be so, TANSTAAFL. What is your suggestion and how does it maintain compatibility with the existing body of code?

This seems worse then remembering, because you still have to remember that your safe-by-default command is unsafe-by-default everywhere you're not usually.

rm doesn’t provide an action summary, does it?

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.

I wholeheartedly agree that rm -i is a terrible UI. However: what presentation of 200 paths would you not glaze over?

Microsoft gets lots of praise for maintaining Backwards Compatibility even if it's Bug Compatibility, yet POSIX gets shit for the same.

The presentation suggested in this very thread would work better for me. I generally pay pretty close attention to package apt/pacman/dnf output because it is all right there in front of me.

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.

Or just add ‘echo’ in front: echo rm ... . Especially when the command is in a loop of some sort.

I set up hourly borg backups instead. That resulted in me aliasing rm='rm -rf' without a worry in the world. So far, I made about ten recoveries and have never lost important data.

If you never rm’ed work you just did not captured by hourly backups, well, lucky you.

kind of the same deal with spooky SQL queries and verifying your where clause with a select first

At least with SQL you can just consistently wrap stuff in transactions, so if you break something you can always revert.

alias rm='rm -i'

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.

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.

All we need is something that will tell us who is right and then impose that vision on everyone.

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

Lots do it's called help. But then they would all have to use the same spec, which we know would never happen.

Like PowerShell?

So I have to take a shell dependency on Node.js?

Hard pass

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.

Maybe the users don’t care about their devices

Haha, I though the same...

> npm install

NEXT!

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.

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-line

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.

A wrapper for Fig that doesn’t require me to create an account in order to use my terminal. I’d say it’s a good thing.

also because you cannot even create an account on Fig nowadays since the signups are currently disabled

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.

https://github.com/withfig/autocomplete is it this?

Looking at the main author's gorhub profile, they forker Fig's repo.

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!

IIRC They were acquired by Amazon. They have a paid offering for shared team environments.

Oh cool, thanks!

The name is terrific.

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 picture the first slide of the deck breaking the name down "in shell intellisense" and people nodding at the back...

First good name to ever come out of Microsoft. I'm sure it just barely succeeded over Visual Windows Subsystem for IntelliSense Core.

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.

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.

Starting to type "dir": "d[el /q /s .]" (press any key to accept)

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.

0. https://githubnext.com/projects/copilot-cli

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?

Yep. I have no idea what "supports fish" means here. From what I can tell you start it and now you're in a totally different shell.

Fig.io with no account and calling home, count me in.

Connecting NPM-powered software directly to my shell? Over my dead body.

Thanks for everyone creating issues. I'm working on addressing all the issues and they'll be included in the next release.

Is anyone else feeling off about typescript in the terminal emulator? I guess it's not worse than TCL or Perl.

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

Thanks, that worked

Awesome in principle, but it appears that it has to take over your prompt to work. Any custom prompt (starship) is replaced, zsh-syntax-highlighting does not work anymore etc.

Too bad…

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

Autocomplete is fast but I/O is really crummy.

Shells and Node.js don't mix well.

Awesome! And it supports fish! Just the other day, I was wishing we had something like this.

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.

i use warp's terminal and i love it, but I think im gonna love this more because its OSS

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.

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.

The TypeScript typesystem is pretty great. And there's always JS to escape to if the typesystem fails you.

It really doesn’t make any sense here. What are we making type safe exactly?

It doesn't make any sense to even complain about Typescript in the first place here. Typescript itself is not being ran when this command is invoked, the npm package for this doesn't even distribute .ts files or a type definitions file.

This is latching on the to the word "Typescript" and immediately beginning the whining.

I mean, right. But back to what I was saying: why typescript? The fact you’re right doesn’t make my question absurd? In fact it kind of completely validates it.

As a user of this project, Typescript is 100% irrelevant, it's compiled to JS and is just a nodejs process and regular javascript at that point. You can go look at what's installed via `npm list -g`, find the path and notice there's not a single Typescript file in the build output.

I wish those aboard the TS/JS hate-train knew what they were even complaining about.

>JS and is just a nodejs process and regular javascript at that point

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

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.

> 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

However, when I initiated a new Bash session within the same Docker container to activate the updated Bash configuration, I encountered the following error:

    bash: /root/.inshellisense/key-bindings.bash: line 1: syntax error near unexpected token `$'{\r''
    'ash: /root/.inshellisense/key-bindings.bash: line 1: `__inshellisense__() {

Due to this issue, I am unable to perform a performance test using hyperfine.

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 pretty sure that the scripts generated by inshellisense are CRLF, and the carriage returns aren't recognized by unix shells.

You should be able to fix it with:

    vi $HOME/.inshellisense/key-bindings.zsh -c "set ff=unix" -c ":wq"

The claim should be tested by measuring the latency of a well-engineered TS-written language service provider. The language services for TypeScript themselves run in far fewer than 100ms, and that is a far more dynamic and complex use case. The shell language service on the other hand is trivially cacheable and on the whole quote simplistic, at least compared to the full TS semantics.

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

In gaming, delay of 100ms is huge enough for anyone besides the most casual players to notice.

Obviously this are different use-cases, but wouldn't be suprised if it was big enough for people to at least notice

>>In gaming, delay of 100ms is huge enough for anyone besides the most casual players to 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)

Depends on what they are waiting for. If there were 100ms of keystroke to paint latency with typing you'd def notice it.

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.

In absolute terms, that's a few hundred million CPU instructions.

Man, we are doing a CLI autocomplete for duck sake, and You guys want to spin ENTIRE FUCKIN BROWSER for it, and then argue "well, it isn't THAT slow, so what's the problem".

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?

Or, spend the 10 minutes learning that Node isn’t spinning up an entire browser.

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 know, JavaScript runs without a browser... There are several JavaScript implementations, most of them aren't bundled with a browser.

https://en.m.wikipedia.org/wiki/List_of_ECMAScript_engines

JavaScript doesn't belong in the shell, thanks.

I disagree. Using the same algorithms, a language like Typescript or Javascript will inevitably be slower than ones that are “closer” to the CPU.

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.

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)

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?

If you're more used to ctrl+r, you could try hiSHtory (https://github.com/ddworken/hishtory)

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.

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.

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

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?

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.

And this will deter me from ~~ever~~ trying Fig. :/

> it requested way too much access to my github account

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"

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.

It's available for Linux and Windows.

That’s what it’s based on.