Live data from Hacker News

Show HN: Inshellisense – IDE style shell autocomplete

github.com

151–160 of 161 posts

Re: Show HN: Inshellisense – IDE style shell autocomplete

#151
post #141

Earlier quoted context omitted.

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

Re: Show HN: Inshellisense – IDE style shell autocomplete

#152
post #69

Earlier quoted context omitted.

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

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.

Re: Show HN: Inshellisense – IDE style shell autocomplete

#153
post #70
post #69

Earlier quoted context omitted.

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?

Re: Show HN: Inshellisense – IDE style shell autocomplete

#154
post #11

Earlier quoted context omitted.

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.

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

Re: Show HN: Inshellisense – IDE style shell autocomplete

#156
post #130

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.

Re: Show HN: Inshellisense – IDE style shell autocomplete

#157

Earlier quoted context omitted.

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 my…

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.

Re: Show HN: Inshellisense – IDE style shell autocomplete

#158
post #100

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

[dead]

Take your toxicity elsewhere, this is no place for this kind of comment.

Re: Show HN: Inshellisense – IDE style shell autocomplete

#159
post #132
post #130

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 parsi…

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