[guessmyname]

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.

[dlivingston]

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?

[yoyohello13]

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.

[dlivingston]

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

[yoyohello13]

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.

[lillecarl]

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

[dclowd9901]

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

[evilduck]

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.

[dclowd9901]

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.

[evilduck]

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.

[Xeamek]

>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

[explaininjs]

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.

[guessmyname]

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

[quodlibetor]

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"

[explaininjs]

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.

[cassianoleal]

100ms is a long time to wait for each completion suggestion.

[emorning3]

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

[Xeamek]

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

[emorning3]

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

[Rapzid]

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

[nu11ptr]

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)

[explaininjs]

The claim isn’t that 100ms is fast, it’s that the blame for the latency lies in the engineering, not the language.

[userbinator]

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

[Xeamek]

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?

[evilduck]

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.

[lillecarl]

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

[stn_za]

JavaScript doesn't belong in the shell, thanks.

[tacker2000]

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