For which packages does VSCode autocomplete work?

Tooling VS Code
,
41

That is easy: split your codebase into packages.

2 Likes
42

I did this, but code introspection was flaky across packages. Sometimes it worked, sometimes not, and I spent a lot of time trying different configurations so that symbols would be indexed properly (dev the package, e.g., using if defined include tricks). Splitting into packages creates well-defined interfaces, but you still may need to look into those packages for a variety of reasons.

Iā€™m not a Julia guru. But I would suggest that if I canā€™t figure it out, then probably a lot of others are in the same situation.

But Iā€™m glad to see the issue is being addressed as you posted above. Somehow this wasnā€™t on my radar, and I casually followed the discourse.

Regardless, I believe Julia has tremendous promise for scientific programming. I think one reason for the slower adoption is the legacy of tooling problems that weā€™re all familiar with: time to first plot, unable to edit structures, no (usable) debugger, and code introspection.

A lot of these are addressed in some way (some better than others). But I wonder if these pain points scared away a lot of potential users for good.

1 Like
43

Sure, but the problem still remains.

1 Like
44

So to address the original question of ā€œwhen should you expect the language server to work?ā€: The following requirements must be satisfied

  • Youā€™ve selected the correct environment (check the Julia env: status bar item)
  • Said environment is fully resolved and instantiated (i.e. thereā€™s a Manifest.toml and the referenced packages are present in the depot)
  • Youā€™re not working on a file in the ./test directory (yes, this is bad, we know)

Of course, this doesnā€™t guarantee that the LS will work (or work well). Common issues are

  • a bug in our parser/linter, which may cause e.g. stack overflows that kill the LS process
  • bad performance because of large ā€œactiveā€ code bases. Note that 100kloc in a project arenā€™t necessarily an issue ā€“ the VS Code extension contains ~270kloc of Julia code and the LS runs fine. Note, however, that
  • changes to package dependencies are not readily propagated; they only affect the currently ā€œactive file treeā€ instead (which is defined by includes, not package dependencies). Dependencies, even deved ones, are effectively treated as immutable.
  • macro support is very bad
  • method table merging can sometimes be wonky, which is especially notable for re-exported methods and stuff like that

Then there are some anti-patterns that are flat-out not supported:

  • LOAD_PATH shenanigans
  • dynamically computed includes

If the requirements stated above are satisfied and the LS isnā€™t working for you as expected, then please open an issue and make sure it includes any errors/warnings from the Output ā†’ Julia Language Server pane as well as as much info about your environment as you can give ā€“ ideally, your code base and the resolved environment (Project.toml + Manifest.toml).

While this is true, many of the problems with the current LanguageServer.jl ecosystem canā€™t be attributed to its static nature. But yes, JETLS.jl is the future :slight_smile:

5 Likes
45

For me, as stated above, things like ā€œGo to Definitionā€ work intermittently and for a seemingly random subset of the codebase. E.g. in one package Iā€™m currently developing, inside one module there is a symbol from a different module in the same package that canā€™t be resolved right now. The other symbol from a third module next to it can, and there is no obvious difference between the two symbols/modules. There are no warnings in the Language Server logs. When I switched the selected environment to a different environment and then back, the symbol that canā€™t be resolved now was briefly resolved, I was even able to click on it, and it went to the correct definition, but a few seconds later that stopped working.

46

You can try to enable the julia.trace.server setting (set it to messages) and check the Output -> Julia Language Server Trace pane for slow requests. Itā€™s very unlikely to show any root causes though, so

47

I donā€™t see any slow responses. The response seems to be ā€œNo Definition Foundā€. I canā€™t share my environment unfortunately. I will try to make a MRE.

48

In this simple example, when looking at Module3.jl the language server does not ā€œseeā€ the definitions of Type1 and Type2 in the other two modules. While I was preparing the example, intermittently it could resolve both types or only one of the two, but not the other one, but right now it canā€™t resolve either one. Very strange, but hopefully this helps to narrow down the issue.

4 Likes
49

I know that it may be just a poor substitute for a fully-working LS, but VSCode provides access to symbols in workspaces. I use it quite often.

1 Like