VSCode prompts non-sense.

[Magicloud]

I am using Bash IDE extension in VSCode. And installed bash-language-server as descripted in its details.

Now I have two problems. One is apparently something is wrong. The other is "I am not sure".

1. Code prompt are all non-sense. For example, I typed "then", I got "thinkjettopbm". I typed "case", I got "catchsegv".

2. Code completion does not work. In my idea, this is something like, when I typed "case", it would insert the "esac". But in my IDE, it does not. Just marks a bunch of lines "syntax error" red underlines.

What should I do?

[rcjsuen]

@Magicloud I highly suggest you provide some screenshots and/or a short video (or animated gif) of the behaviour you are seeing.

[skovhus]

Code prompt are all non-sense. For example, I typed "then", I got "thinkjettopbm". I typed "case", I got "catchsegv".

Code suggestions are based on executables on our path. That means that thinkjettopbm is a valid command in a shell script. Would be nice with more context-aware suggestions though. PRs and suggestions are more than welcome. :)

[Magicloud]

Following pics show both problems. Sorry, I could get GIF recorder (peak) to work with my desktop.

[thomasjm]

Looking at the server code it seems that bash-language-server always appends all executables it can find to the autocomplete results, and then leaves it up to the client (VSCode or other IDE) to do its best to filter them (!).

https://github.com/mads-hartmann/bash-language-server/blob/ba43db6e5b6a2f755d04e4ce97193b9849720458/server/src/server.ts#L187

I think that's why you're seeing these results.

From what I've seen of other language servers, bash-language-server should be doing more work here...I would hope it could use its understanding of bash grammar to a) identify places where executable commands should actually appear, and b) filter them based on the token that has been typed so far at that point.

[thomasjm]

@skovhus any chance this could be a high priority fix? I think it's more of a serious bug than an enhancement.

I just dug into this in more detail in Atom. When I type something like ech (expecting to see completions like echo), bash-language-server returns almost 3,500 results, almost all of which are nonsensical. The only reason completion works reasonably at all on Atom is because Atom itself is smart enough to prune the results before showing the autocomplete popup.

For other clients that don't filter the results by default, this makes bash-language-server completion almost unusable.

FWIW, I think it would be simple to compare the executable strings against the token where the cursor is found before returning the list. Thanks!

[skovhus]

Agree. 👍 Contributions are more than welcome.

[skovhus]

@thomasjm is this still a problem?

[yangyingchao]

I'm using the latest release of bash-language-server with emacs, and I can reproduce this issue. Really annoying... It would be great to have thomsjm's pull request tested and merged...

thanks

[thomasjm]

I've not found time yet to write tests for the PR -- any help pushing it over the finish line would be welcome :)

[skovhus]

Several fixes for this was released as bash-language-server@1.10.0 and the VS Code client version 1.7.0.

@Magicloud @yangyingchao please let us know if this works for you. And thanks for reporting these issues.

[yangyingchao]

Still not resolved when using emacs + lsp-mode ...

[skovhus]

@yangyingchao which OS? And which version of bash language server are you running?

[yangyingchao]

I tested both Mac OS 10.13.6 and RHEL 7.3, with bash-language-server 1.14.0. js version: v10.20.1 (on OS X), and v8.11.4 (on Linux)

Thanks.