Notice two2 = too (which is not defined).
I do have the “missing references” enabled:
Any idea what is wrong? Sublime Text (4). On windows.
It shows up in vsc:
But so does a gazillion bogus missing refs. Obviously, if I have using PGFPlotsX at the top,
@pgf should not be a missing ref.
I can’t replicate the missing refs issue in Vim (or VSCode), so probably a configuration issue where the server doesn’t pick up your settings, ignores them, or sets its own defaults.
Regarding the bogus missing refs, I can’t replicate that either. Are you sure you have PGFPlotsX in the active project? (Having it in the default environment is not enough.)
You are right, PGFPlotsX was not a good example. But even after I make sure to initialize the project, I get incorrect missing refs:
And lots of such are reported (922).
BTW: 553 of those missing refs are from Manifest.toml. Is that normal?
Julia LSP should only be fed Julia files, so that seems oike another configuration issue in the Sublime LSP integration perhaps.
No, sorry, this is VS Code. And I don’t see any option for selecting which files should be seen by LSP.
All of today’s examples are from VS Code.
I think I solved the puzzle why things in Manifest.toml were being reported as “Missing References” in VS Code: There are two values that turn that reporting on, all and symbols.
It needs to be set to symbols so that only Julia file are taken into consideration.
That leaves the question why so many objects are being reported as “Missing References”
when clearly they should be known. Example:
ACol is the current environment, so why the missing references on line 4?
I wonder if it has anything in common with the apparent problem VS Code has with
suggesting completions from the current package?
Known issue: LanguageServer does not index active project/package · Issue #988 · julia-vscode/LanguageServer.jl · GitHub
Filed it myself 
Note to self: eat more wallnuts (for better memory…).
1 Like
For Sublime LSP, you need to put your server configuration options into a "settings" object, like this:
{
"settings": {
"julia.lint.missingrefs": "all",
},
}
1 Like
AFAICT, VS Code (or the Language Server, more precisely) has trouble with source code that uses the current package but is not part of it. Such as scripts, that are typically placed outside the src subdir (which seems to be the case of your acousticcolorplot.jl file above).
I know of 2 (rather hacky) ways to work around this problem:
-
put the bulk of the script code in a function inside the sources of the package (
AColin your case). Then your script becomes mostly empty: it reduces to something likeimport ACol ACol.acousticcolorplot(...) -
trick the Language Server into thinking that your script is actually part of the package sources (but in a separate Module so that it sees the same exported names as an independent piece of code). It seems that this can be achieved by putting something like this in
ACol.jl:@static if false module Foo include("../myscript.jl") end end
4 Likes
Oh, I see! Sorry, I missed this point. Many thanks, missing references are shown in the diagnostics panel.
But, now there are too many. Example:
Obviously, I do have those packages in the environment!
This is the best explanation of the problem I have heard so far.
Thank you a lot, @ffevotte. Yes, I have passed a lot of time this morning asking me why when I work in the package everything is working nicely, but when I use the main program that use my package, it did not find it, even when in the directory of the script there is the same Project.toml.
I have the following schema:
pract.jl: script to use the package to solve the problem.
Project.toml: dependencies.
src/… implementation of the package.
test/… tests.
When I work in src/ it is working nicely, but when I use pract.jl is not working at all.
I tried the first option, and it is working. However, I am not sure about the second one, because it is not working in my case, could you give a better idea?
However, thanks a lot.
First, be aware it’s very hacky and messes up a bit with inline evaluation (which I don’t use much because I actually use Emacs for my day-to-day work). But let me try and give a step-by-step procedure that demonstrates this trick on a simple package like Example.jl. You should be able to reproduce this on your system.
First, git clone https://github.com/JuliaLang/Example.jl, open the project in VSCode and add a script.jl file at its root. It should look like this:
Example.jl
├── Project.toml
├── script.jl # <-- newly added file
└── src
└── Example.jl
# script.jl
using Example
println(hello("World"))
At first, LanguageServer is not happy with the reference to Example.hello: for example, neither the inline doc nor the “Go to definition” command work.
Now, if you edit src/Example.jl to read:
module Example
export hello, domath
# [...]
# I'm skipping the definitions of `hello` and `domath`
# Add this part to "trick" LSP into thinking that `../script.jl`
# is actually part of the sources
@static if false
include("../script.jl")
end
end
Now VSCode / LSP should be more happy and find what hello refers to in script.jl. Does that work for you?
4 Likes
@ffevotte - That @static if false trick worked for me in Emacs, and I wanted to thank you for sharing that. However, I wish there were a better way that didn’t involve tricking the LSP server. For example, I wish I could tell the LSP server that all Julia files in the bin/ directory are part of the project and should be able to see the current package.
Another way of tricking vs-code to get intellisense: define a macro like this:
# inside your package entry point
macro ignore(args...) end
# then, "include" the julia files you want intellisense to work
@ignore include("../examples/example.jl")
@ignore include("../examples/script.jl")
2 Likes
This worked for me on (neo)vim! This has been driving me crazy for weeks. Thank you.
But why does this work exactly?
As far as I understand, LSP only has limited knowledge about the semantics of Julia. It understands the meaning of include but not @static if false. So after analyzing these lines, LSP believes script.jl to be part of the project sources. And code references always work more reliably when editing source code that is “inside” the project.