Does not process includes as well as nimsuggest CLI (MWE)

[JorySchossau]

For some reason, this isn't working as well as nimsuggest, even though isn't it relying on nimsuggest?...

	"settings": {
		"nim.project": [
		"main.nim", "first.nim", "second.nim" // I've also tried just main.nim
		]
	}

# main.nim
include first
include second

#first.nim
type First = object

#second.nim
var first:Fir  ## <-- try to autocomplete this

nimsuggest correctly shows completion whereas for some reason this plugin doesn not.

nimsuggest main.nim
sug second.nim:2:11
sug	skType	main.First	First

[RSDuck]

it kind of does work in VSC. Here's the things I did:

1. setup all the files you described here
2. set main.nim as the only project file
3. switch to second.nim so it will be the first editor to be opened the next time VSC in opened
4. close VSC
5. open VSC again
6. now press ctrl+space to open suggestions (after Fir).
7. First will be suggested
8. Though once you goto definiton and return again it's all messed up

EDIT: though what's strange is that I tried doing the last step with manually and it seems not to happen.

[JorySchossau]

How odd! It does indeed work for a hot second.
If any nim file other than second.nim is also open, then simply switching focus to any source code tab away from second is enough to mess it up.
Do you have any insight why this might be the case? I'm hoping to take a stab at fixing this later, but I have no idea what I'm doing yet.

[JorySchossau]

Well, I'll start to keep notes here.

vscode-nim (vscn) does the sensible thing and keeps nimsuggest as a process running in the background for each unique project definition you are running. This means you can have multiple VSCode instances up working on different nim projects and still have spun up versions of nimsuggest for each one for query performance.

My guess is that this process handling gets messed up when switching the editor between files and querying nimsuggest with different target files. If instead we close nimsuggest every time after a query (such as a suggest lookup) then we get fixed behavior for this issue (I tested this), with correct results coming back each time. But the performance cost of this is quite large. It would be ideal to find a way to keep the process open.

The relevant files so far are, you guessed it, src/{nimSuggest.ts,nimSuggestExec.tx}.

To get set up developing, do these steps:

• install nodejs
• git clone this repo
• cd into repo
• npm install (and ignore auditing errors)
• start up VSCode in the repo dir code .
• say 'yes' to install required files if it still asks you
• press F5 to launch a test instance of VSCode in which you can try out the plugin on a nim project.

[RSDuck]

if it's really just a nimsuggest issue then could you put together the steps to reproduce and make an issue on it's issue tracker?

[JorySchossau]

if it's really just a nimsuggest issue then could you put together the steps to reproduce and make an issue on it's issue tracker?

Oh, sorry! I didn't mean to give the impression I thought it was a nimsuggest issue. My current thinking is that this is a VSCode-Nim issue.

Cases where autocompletion works correctly with the above MWE:

• command line REPL interfacing directly with nimsuggest
• NeoVim Nim plugin alaviss/nim.nvim (it also leaves the process open and uses a port to communicate)

Cases where autocompletion fails:

• VSCode pragmagic/vscode-nim

[RSDuck]

I figured it out, atleast somewhat. There's a problem with the dirty files, idk what but if you instead pass the filename again it works for me (https://github.com/pragmagic/vscode-nim/blob/master/src/nimSuggestExec.ts#L200).

[JorySchossau]

Thanks! That helped me figure out what was going on. Nimsuggest assumes unique dirty files, and vscode-nim uses 1 shared file it always overwrites. The remaining issue is maybe to add a unique ID when it makes the tmp dirty file path (see the PR for details).

[JorySchossau]

Remaining unique ID issue fixed in latest PR commit. I think this is ready for merge unless there's any outstanding issues anyone sees or the author disagrees with.