There is an issue at the official MS/vscode repo: microsoft/vscode#396 about adding support for multiple project folders. It has received a lot of attention and MS is asking for a few volunteers they can interview as they consider adding this feature. I think developing Julia code, from my experience, is greatly aided by the ability to open multiple package folders. I do this all the time in Juno and it was one of the first disappointments I bumped into when trying VS Code for Julia development.

If you have any opinion either way, maybe you can chime in over there. Just FYI.

For example how to configure the path.

This case should be treated, maybe by reparsing the module block after droping the line contains "module "

Trying out the beta2, the extension seems to work until I get the following error message bar in vs code:
The julia Language Server server crashed 5 times in the last 3 minutes. The server will not be restarted.

Restarting does not help. I have no idea how to debug vs code, but let me know what I can do to assist.

julia> versioninfo()
Julia Version 0.5.0
Commit 3c9d753 (2016-09-19 18:14 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, haswell)

As a next step in terms of features I was thinking of integrating some static code analysis type features. First thoughts as to what it would do:

• Parse the file you are working.

• Know what types/functions etc. are being defined thus providing hover, completion and signature help for them. Also for obvious cases we could learn the type of variables (e.g. those bound to the result of a constructor).

• Parse inside each of these top level blocks providing the same things at the local level only (e.g. for a function we'd know the type of the argument if specified).

Key to all of this is retaining the relation between the AST representation and the layout of the text which precludes an easy solution. I think we could either start ground up or attempt to fork Lint.jl (which does all the scope tracking) adding the AST->document range relation. The latter would also have the benefit of not repeating the work the linter does twice.

Thoughts?

The proper way to do this is to use something like this for the character field of the start part of the range, and then typemax(Int) for the character field of the end part of the range, like here.

Adding Intellisense to functions and variables that have type definitions

Upstream problem, see microsoft/vscode#8070.

Maybe we need a configuration option to allow JULIA_PKGDIR to be directed at the user's home package directory?

There is a race condition with precompile right now. Julia 0.5 has the --compilecache=no, which we should try for the linter process once we switch to julia 0.5.

@ZacLN I think it would be good if we released a v0.5 soonish, and then moved the whole language server code into its own package for a VS Code extension v0.6 release.

One big reason for moving the language server into a package is that we can then start to setup a whole testing infrastructure for it, which seems really key.

So I'm trying to triage right now what should go into v0.5, and what we should do in later releases. Maybe we can use this issue here to discuss that.

The one PR that I'm unsure about is #54. Right now I can't really test it because #57 is blocking things for me right now. But you also seemed to think that #54 is maybe a bit flaky? If so, should we wait with it until v0.6, or do you think it is just a small extra work to get it into a stable state?

I'm also still fighting with #31... If I can't find a good solution soon, I might just remove that functionality for now...

If the VS Code extension detects a change of the executablePath configuration, it should restart the language server (or start it, if it hasn't been running).

JunoLab/Weave.jl#80 added inline code. We should update our grammar file to reflect that.

@mpastell FYI

This happens sometime after calling Go To Definition on a method:

ERROR: LoadError: Unexpected character '%' in host
 in parse_authority(::String, ::Bool) at C:\Users\Basti\.vscode\extensions\julialang.language-julia-0.5.0-beta.1\scripts\languageserver\julia_pkgdir\v0.5\URIParser\src\parser.jl:112
 in parse_url(::String) at C:\Users\Basti\.vscode\extensions\julialang.language-julia-0.5.0-beta.1\scripts\languageserver\julia_pkgdir\v0.5\URIParser\src\parser.jl:291
 in should_file_be_linted(::String, ::LanguageServer) at C:\Users\Basti\.vscode\extensions\julialang.language-julia-0.5.0-beta.1\scripts\languageserver\utilities.jl:123
 in process(::JSONRPC.Request{Val{Symbol("textDocument/didOpen")},DidOpenTextDocumentParams}, ::LanguageServer) at C:\Users\Basti\.vscode\extensions\julialang.language-julia-0.5.0-beta.1\scripts\languageserver\provider_misc.jl:27
 in run(::LanguageServer) at C:\Users\Basti\.vscode\extensions\julialang.language-julia-0.5.0-beta.1\scripts\languageserver\languageserver.jl:30
 in include_from_node1(::String) at .\loading.jl:488
 in process_options(::Base.JLOptions) at .\client.jl:262
 in _start() at .\client.jl:318
while loading C:\Users\Basti\.vscode\extensions\julialang.language-julia-0.5.0-beta.1\scripts\languageserver\main.jl, in expression starting on line 43

If the Julia terminal process is disposed of it leaves the vscode-language-julia-terminal-... socket in place causing an error on the start of a new process (though it still runs with no problems).

Is there a way the the terminalserver can handle the kill process and close the socket on exit?

Either by right clicking and/or ctrl + clicking names of variables/functions/types

For example, if I press ctrl-Enter at first line of this expression:

for i in 1:10
    print(i)
end

Only for i in 1:10 part is sent to terminal.
It's working though I have to keep pressing ctrl-Enter to evaluate whole expression.
But, below is not working.

string(1,
2,
3)

When I press ctrl-Enter at first line, only string(1, is sent to terminal and ) is automatically appended, which is not my intention.
It would be good if whole expression is sent to terminal as Juno.

I'm on version 0.5.0-beta4.

Right now F12 can often open files from e.g. Base. When those files are opened, the linter shouldn't provide diagnostics for those, I think, but should only lint files in the current folder open in VS Code.

VS Code has this keyboard shortcut on Linux and Windows:

{ "key": "ctrl+enter",            "command": "editor.action.insertLineAfter",
                                     "when": "editorTextFocus && !editorReadonly" },

The Julia extension overrides it with language-julia.executeJuliaCodeInREPL which is quite annoying for people who use the normal behavior very often when editing code.

Please help beta test the next release! To try it out, follow these steps:

1. Download and install VS Code from here.
2. Download the beta from here.
3. Install the extension by running code language-julia-0.4.0-beta.1.vsix from the directory where you saved the language-julia-0.4.0-beta.1.vsix.
4. Start VS Code and play around.

I would especially welcome testing of the linter. The linter should be triggered by simply opening a .jl file. It will take a while (couple of minutes) until the first linting results are shown when you do this the first time (a lot of package installation and precompilation happening in the background), but then results should show up instantaneously (both as you open a file and edit).

If you tried the beta, please report back here with a comment whether it worked and on what platform you were. Please also report if things worked, not just problems. I am especially looking for people on macOS to try this out (I don't have a Mac).

HI,

This is looking great! I just tried installing it and hit a snag because VS Code could not find my julia.executablePath. It turned out the reason is I installed Julia in: C:\Program Files (x86) and VS Code was not recognizing the space in the path. To fix it, I had to set the path to C:\\PROGRA~2.

Documentation could use a minor update.

Best regards,
Eric

Hi,

I see that I can create keyboard shortcuts in keybindings.json, but what is the command to open the Julia terminal? Thanks!

@davidanthoff could you please try the following code

function run_code(code)
    repl = Base.active_repl
    julia_mod = repl.interface.modes[1]
    on_enter = julia_mod.on_enter
    on_done = julia_mod.on_done
    julia_mod.on_enter = (s) -> false
    julia_mod.on_done = (args...) -> nothing
    eval(parse(code))
    julia_mod.on_enter = on_enter
    julia_mod.on_done = on_done
    s = Base.LineEdit.init_state(repl.t, repl.interface)
    Base.LineEdit.refresh_multi_line(s)
end

What the code does is simple. First, before the terminal server evaluates code, it disables the "on_enter" and on _done methods of the julia prompt, which are activated when user press one or multiple '\n'. After evaluation, it changes the on_enter and on_done methods back.
You will see that the result is shown after the current user's text, and a new prompt. To go back editing just press back_space.

I haven't tested in the TerminalServer but it works in the REPL
For example, run
@asyn run_code("sleep(10); println(\"OK\")")
and try to input something. After OK is printed, you can press back_space to get back to where you were.

Is this behavior what you're looking for?

Instead of ex.args[1].args[1], it should be string(ex.args[1].args[1]) in the following line
https://github.com/JuliaEditorSupport/julia-vscode/blame/master/scripts/languageserver/parse.jl#L108

If one sends code from a given file to the REPL, make sure the current directory of the REPL process is the one where the file is located.

This is probably difficult with the current design, but once we move back to the model where the code is sent to the REPL process over a named pipe, this should be simple.

Essentially the REPL prompt should be hidden, then the code from the editor be executed, then the REPL should appear again.

This would add a command "julia: Run tests" that would run the file test/runtests.jl if present.

Any word on a release date for a version compatible with Julia 5.0?

I've tracked the problem down to this: we get rootPath as c:\Users\anthoff\source\fund.jl, but URIs on Windows look like this file:///c%3A/Users/anthoff/source/fund.jl/src/helper.jl. So a simple string comparison doesn't work... I think we should stick with the URI format as our key in the dictionary, because that is the format we need to return in the various JSON messages. But for the comparison we'll have to convert the URI format into a normal windows path format, and then do the comparison in isworkspacefile based on that.

As you might be aware, the Julia linter still has an issue with relative module paths. I love the functionality that the linter provides, but due to this issue it's giving me so many false-positives that I'd like to have a way to disable it. Would it be possible to add a configuration option for this? I gave it a shot myself, but there are so many ways that this can be done (considering how you're interfacing with Julia from VS Code) that it's probably best if you tackle this yourself—most notably because you'll be able to consider how future functionality might hook into the same configuration system.

Thanks for the great package!

I was able to crash it again. Sorry :) This time playing with the latex completions.

I've noticed not all latex symbols are available, eg "\\^2". Also doing two right after one another wont work (eg. βᵢ).

Here's the output on error. Again, let me know what I can do to assist.

ERROR: LoadError: UnicodeError: invalid character index
 in slow_utf8_next(::Array{UInt8,1}, ::UInt8, ::Int64) at ./strings/string.jl:67
 in next at ./strings/string.jl:92 [inlined]
 in getindex(::String, ::Int64) at ./strings/basic.jl:70
 in next at ./strings/types.jl:113 [inlined]
 in search(::RevString{String}, ::Array{Char,1}, ::Int64) at ./strings/search.jl:12
 in rsearch(::String, ::Array{Char,1}, ::Int64) at ./strings/search.jl:162
 in bslash_completions(::String, ::Int64) at ./REPLCompletions.jl:364
 in completions(::String, ::Int64) at ./REPLCompletions.jl:455
 in process(::JSONRPC.Request{Val{Symbol("textDocument/completion")},TextDocumentPositionParams}, ::LanguageServer) at /Users/ken/.vscode/extensions/julialang.language-julia-0.5.0-beta.3/scripts/languageserver/provider_completions.jl:4
 in run(::LanguageServer) at /Users/ken/.vscode/extensions/julialang.language-julia-0.5.0-beta.3/scripts/languageserver/languageserver.jl:30
 in include_from_node1(::String) at ./loading.jl:488
 in include_from_node1(::String) at /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib:?
 in process_options(::Base.JLOptions) at ./client.jl:262
 in _start() at ./client.jl:318
 in _start() at /Applications/Julia-0.5.app/Contents/Resources/julia/lib/julia/sys.dylib:?
while loading /Users/ken/.vscode/extensions/julialang.language-julia-0.5.0-beta.3/scripts/languageserver/main.jl, in expression starting on line 41
[Info  - 11:17:54 PM] Connection to server got closed. Server will restart.

I start writing the following in a julia file:

randn(

At this point the signature help appears. If I then close the paranthesis and move the cursor to the end of the line (i.e. after randn()) the server crashes.

@ZacLN Could you have a look? I think the problem is somewhere in get_word, but I don't understand that method well enough to fix this.

Might we want to split the language server Julia code into a different repo leaving just the startup, version checking and package installation magic in here?

I just figured out how we can use the Atom julia grammar in this extension. All we have to do is convert the cson file into a json file, and then we can use that file in the extension here. Converting is simple using this.

The real question is, should we do that? My sense is that the grammar file over there probably gets a lot more attention than our version here. @be5invis what is your take on that? I know you added a few things recently to our grammar file, do you know whether those things are taken care of in the atom grammar already?

In some cases I get w whole bunch of red and green underlines in a perfectly functional code.
Being able to disable the underlines would be good.

This is far down the road, but in general we should be able to use this in the same way it is used by this.

This is currently blocked by JunoLab/Weave.jl#76

The problem right now is that the VS code extension tries to open a named pipe, but if the terminal server is being started as part of the same command, the named pipe might take a few moments to be up and running. We need to somehow try to connect multiple times (say 3 times), with a little wait between them, and only then give up.

At the moment only the first period is highlighted
@be5invis, maybe you could add this to the operator list?

@ZacLN I think one of your earlier PRs had some typescript code that made auto indentation much better. Would be great if you could submit a PR with that!

Currently we are waiting for some more work upstream. See this discussion.

For example, the hover doc for is_windows() will show a link.