pragmagic / vscode-nim

An extension for VS Code which provides support for the Nim language.
Other
238 stars 37 forks source link

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

Open JorySchossau opened 3 years ago

JorySchossau commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

RSDuck commented 3 years ago

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 commented 3 years ago

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:

Cases where autocompletion fails:

RSDuck commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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.