[HN Gopher] Show HN: Inshellisense - IDE style shell autocomplete
___________________________________________________________________
Show HN: Inshellisense - IDE style shell autocomplete
I built this terminal native runtime for Fig's autocomplete to
support Windows and Linux. Would appreciate any feedback on it!
Author : cpendery
Score : 97 points
Date : 2023-11-06 19:15 UTC (1 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| 100k wrote:
| The name is terrific.
| exikyut wrote:
| 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......
| Y_Y wrote:
| 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.
| smoldesu wrote:
| Did you check the page? It's MIT-licensed and isn't about GPT
| or text generation. It's Intellisense, for the shell.
| hui-zheng wrote:
| then what makes it better than withfig/autocomplete?
| boxed wrote:
| 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.
| wrs wrote:
| That's what it's based on.
| Timon3 wrote:
| It's available for Linux and Windows.
| strbean wrote:
| 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.
| monkellipse wrote:
| 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?
| biellls wrote:
| A simple approach might be that if the resulting exit code is
| not 0 it won't be used to complete in the future.
| owlstuffing wrote:
| 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.
| mksybr wrote:
| 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
| tombert wrote:
| I feel like I've trashed millions of files I shouldn't have
| with `rm` and trying to be clever with regular expressions.
| doubled112 wrote:
| I've done this enough times I use `ls` first, then `rm`
| tombert wrote:
| 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.
| doubled112 wrote:
| 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.
| tombert wrote:
| 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.
| doubled112 wrote:
| That's actually a way better experience than no
| confirmation and confirming each item individually.
| teddyh wrote:
| Note: Normal shells use glob(7) expressions, not regular
| expressions.
| tombert wrote:
| 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!
| guessmyname wrote:
| 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.
| explaininjs wrote:
| 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.
| cassianoleal wrote:
| 100ms is a long time to wait for each completion suggestion.
| nu11ptr wrote:
| 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 wrote:
| The claim isn't that 100ms is fast, it's that the blame
| for the latency lies in the engineering, not the
| language.
| emorning3 wrote:
| 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-...
| guessmyname wrote:
| > _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/micro
| soft/inshellisense/blob/main/shell/k...
| dlivingston wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| HomeDeLaPot wrote:
| Awesome! And it supports fish! Just the other day, I was wishing
| we had something like this.
| Night_Thastus wrote:
| 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!
| boxed wrote:
| 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.
| schmorptron wrote:
| The readme for this project states that it supports fish,
| does it replace the prompt?
| boxed wrote:
| I wish I had something like this without it replacing the shell
| prompt with `>`.
| filterfiber wrote:
| Is this fully local? I glanced around and didn't see any mention
| of chatgpt/gpt/codex so I'm thinking it is?
| trey-jones wrote:
| 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.
| Dudester230602 wrote:
| 1980s... but like 2020s-style.
|
| Coming next: auto-complete for punch cards.
| leshenka wrote:
| can you expand on this?
| askiiart wrote:
| 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
| Dudester230602 wrote:
| 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.
| dang wrote:
| 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.
| mschrage wrote:
| 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!
| trey-jones wrote:
| I'm pretty sure this is just a wrapper for Fig.
| curiousgal wrote:
| Looking at the main author's gorhub profile, they forker Fig's
| repo.
| nextaccountic wrote:
| https://github.com/withfig/autocomplete is it this?
| xnx wrote:
| Starting to type "dir": "d[el /q /s _._ ]" (press any key to
| accept)
| bestest wrote:
| 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?
| serial_dev wrote:
| 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.
___________________________________________________________________
(page generated 2023-11-06 21:00 UTC)