[ANN] Julia for VS Code 1.5 released

Hey folks,

we’ve just released version 1.5 of the Julia extension for VS Code. Here are some of the highlights in this (and the unannounced 1.4) release, but feel free to check out the changelog anyways.

Runtime diagnostics/JET.jl integration

The custom application/vnd.julia-vscode.diagnostics MIME type allows packages to display runtime diagnostics directly from your REPL. I’m currently only aware of JET.jl using this, but there are many possible applications.

Interactive plot pane

The plot pane is now interactive – you can zoom and pan plots (hold Alt/Option for that functionality) as well as save them to disk or your clipboard. Thanks to @Abdulrhmn_Ghanem for the implementation of this feature!

image

Improved table viewer

The integrated table viewer got mostly re-implemented and is more powerful (and prettier) than ever before. It can display arbitrarily large Tables.jl-compatible datasets (although too many columns may cause issues), supports filtering and sorting (yes, even for tables with a million rows) as well as support for copying the selected rows to the system clipboard.

Limited support for runtime-based completions

The extension will now provide auto-completions based on your REPL state in some cases:

Better code formatting based on JuliaFormatter.jl

The Format Document and Format Selection commands now use JuliaFormatter.jl to make your code look exactly how you want it to. Note that all configuration options for code formatting were removed; you will need to use a .JuliaFormatter.toml instead.

New default keybindings for code evaluation

We’ve moved to a new set of default keybindings for inline evaluation to stay in line with the keybindings used for notebooks. Check the individual commands in the command palette for more details or take a look at the source directly.

Various improvements to Language Server startup performance and responsiveness

The language server should be substantially more responsive with this release, especially on startup (instead of blocking all interaction). Package indexing is now more “interrupt-safe”, because caches are written more often. At the very least, the UI should give you a clue as to what exactly is going on at the moment and how far along we are.

Unfortunately, there still are performance issues in the LS, which may cause it to get stuck trying to lint your code for multiple minutes in some rare circumstances, especially with large codebases. We’re working on tracking down what exactly goes wrong there.


As always, don’t hesitate to open an issue if you run into problems, or reach out here on Discourse, Slack, or Zulip.

102 Likes

Looks great, thanks to all contributors!

Now you might not be surprised by this question given I’ve been banging on about this ever since Juno was put into maintenance mode… could you elaborate on the “some cases” in which auto-completions will work? What are those cases? And do they include the all important names-of-DataFrame-columns?

3 Likes

I knew you’d ask that :slight_smile: We’re handling properties and dict indexing only, IIRC, although the DataFrames case in particular is broken atm. Should have a fix for that in the next few hours though.

5 Likes

Hm, I seem to be struggling even with the Dict case:

Julia extension shows version 1.5.4, and I’m on VSCode insiders build if that makes a difference!?

You can’t access dict keys with ., only with [].

4 Likes

Haha, yes I suppose it would be surprising for VSCode to support something which Julia the language doesn’t actually support :slight_smile:

I guess that’s what you get for never really working with Dicts and trying this in the same file where I was trying out the DataFrames autocompletion. Something more useful:

image

which is great!

5 Likes

Could you elaborate on the .JuliaFormatter.toml file? Is it per folder? For VS Code? Where should it be?

3 Likes

See Configuration File · JuliaFormatter.

EDIT: But some further instructions about locations that are supposed by VSCode integration might be useful. E.g. can it look up for a configuration located under home directory (i.e. which might be outside of the current project) ?

5 Likes

Thanks for this new release: it looks awesome!

It looks like the name of the commands changed a bit too. For those who (like me) might be a bit lost, I found clear descriptions of the behavior of each command in the updated development version of the documentation:

https://www.julia-vscode.org/docs/dev/userguide/runningcode/#Running-code-in-the-Julia-REPL

(The official julia-vscode site currently points to the documentation for version 1.3.32; that might change soon)

7 Likes

This is super nice. A small feature question (I can open an issue if you prefer). When filter/sort rows of a table in table view it could be considered to use the “Row” column (leftmost one) to show the row number in the original table. Currently it is just a sequence of numbers. I realize that both approaches could be useful, but I feel that having an information about row number in the source table is useful more often (as you can later use it to e.g. index into the table row you have filtered)

5 Likes

Yup (thanks for the reminder).

Please do. This is tricky for some reason I can’t quite recall…

1 Like

Thank you all so much for your work! The improvements here are really gigantic, unrecognizable from the last time I tried VSCode!

We’ve definitely had this discussion before on TableView

Just trying out the new table viewer, I see the following:

when I then click on the table icon next to testdf in the Julia extension sidebar, I get:

image

when I then type something into the filter field for x2, I get an error in the REPL, but before I can see what it is, the entire extension crashes with this error message:

image

Any ideas where I’m going wrong this time? (I’ve also sent a crash report if that helps)

2 Likes

Have there been any changes to scoping?

I am always using this command
“Julia: Execute Code Cell in REPL and Move”

My layman approach for debugging modules has been:

  1. define some variables in global scope (e.g. the inputs of a function of my module), say dfis defined in global scope
  2. open MyModule/src/somefn.jl and execute certain lines within a function I am trying to debug

This does not work anymore as df is not defined within MyModule

Any ideas?
I don’t think I am the only one having used that approach.

1 Like

Just a bug with async tables… Can repro and will fix.

No, nothing changed here. Make sure you’re in the same module (check the lower right) both times, or prefix your variables appropriately.

2 Likes

Thanks. Changing the module does the trick.

I note that I also had to enable these settings (which I think were default before):
‘Print executed code in REPL and append it to the REPL history’
‘Julia › Execution: Result Type → REPL’

How about this:

My favourite command ‘>Julia: execute Code in REPL and Move’. The docs say:

Whenever, there is some Julia code selected in the currently active editor, this command will execute the selected code. If no text is selected, the command will identify the extent of the top-level language construct that the cursor is located in (except modules) and execute that code block.

Is the last sentence new?
I loved the ability to go ‘line by line’ with the cursor at the end of the line.
Now, it seems, I cannot do this anymore (in a function of a module), or is there another command for this?

1 Like

You’re looking for Julia: Send Current Line or Selection to REPL, which doesn’t have a default keybinding anymore.

4 Likes

Thanks. Much better.
This also resolves my previous question as this command (which I have been using for ages) has no awareness of the module/scope.