Support Interactive Window of vsocde.

[janckerchen]

julia-vscode's support for the vscode notebook api is quite complete, but it's barely mentioned in the documentation. So it's possible that the team has worked on Inteactive Winddow as well, but I haven't seen it, so if that's the case please let me know.

We've got support for cells in julia code, we've got support for notebooks, and it looks like we're getting pretty close to Inteactive Winddow (I'm not sure if it's vscode standard components or part of the jupyter extension). It adds codeLens buttons for cells in code, which can send the cell to Inteactive Winddow on the right for execution (there's a configuration to control whether the selected code is sent to windown via shift+enter instead of REPL). Inteactive Winddow looks like a notebook UI, but with an input box at the bottom, which is meant to enhance the REPL experience. The window cell of the run result can only be viewed but not modified. Meanwhile, there is a mapping between the code cell and the window cell, so you can easily jump between them.

This is a very good way to study julila, and will be very friendly to newcomers to julila.

[RoyiAvital]

I think it would have been better just to embrace VS Code's native Interactive Window instead of recreating it on the Julia Extension. MS has offered support to Julia in Interactive Window. See https://github.com/microsoft/vscode-jupyter/issues/273.

Maybe more support, specifically from the developers of the Julia extension will make MS enable this.

[davidanthoff]

The interactive window stuff is not part of base VS Code, it is part of the Jupyter extension.

I've been thinking a bit what we could do in the spirit of this without taking on a new dependency. Here is one idea: 1) I'm definitely in favor of adding code lenses for executing cells inside jl files if we detect code blocks in there. I think that should probably be implemented in the LS. 2) I think we could add a feature where one can attach a "history notebook" to our running REPL. In that case, whenever one sends a command for execution in the REPL, the extension adds a new cell to this connected "history" notebook with the code that was sent, and then also adds the result from the execution to that notebook. I think from a UI point of view that would pretty much do the same thing as the interactive window, wouldn't it?

[RoyiAvital]

I think the big novelty of Interactive Window is the support for the JupyText format.
Personally I'd like to have the MarkDown + LaTeX Rendering. I find it an important feature. You may think about it as Weave.jl Next Gen.

[janckerchen]

2. In that case, whenever one sends a command for execution in the REPL, the extension adds a new cell to this connected "history" notebook

REPL is used very frequently, especially when executing code line by line, and if the notebook is synchronized with it, it becomes fragmented and unusable. For my use case, REPL and notebook take on different demands, and in REPL I'm trying something， and keep the parts that are worth summarizing in a single notebook.

I'd be inclined to use codelens to explicitly add cells to the notebook, 或者先选择部分代码再通过某个快捷键送入 notebook。 These are ways to make feeding a notebook less arbitrary, better differentiate between REPL and notebook values.

[RoyiAvital]

@davidanthoff , By the way, you mention you don't want the Jupyter extension to become a dependency.
The question is, if Jupyter Extension is installed, could we have those features?

If I get the Interactive Window experience, all I want from the Julia extension is 2 things:

1. The LSP server.
2. Debugger.

All the other features are not needed.

All the rest are implemented beautifully in VS Code + Jupyter Extension to begin with. Currently, the Julia Extension tries to build its own world which is lacking in comparison (Resources).
Moreover, it even ruins some other features of VS Code (For instance using F2 for variable name change).

As you wrote in Discourse, you have less resources than needed, why not use the work of others? All the developer there wanted is your confirmation the feature will be useful for Julia.

[janckerchen]

If jupyter had zero dependency on python, I'd agree with @RoyiAvital that it's unwise to rely on jupter if jupyter can't run completely free of python. Especially since notebook has become a standard api for vscode.

I've seen other language communities (like typescript) start to support their own notebooks, and the features of each language are only as good as their specialized environments. jupyter will ultimately be able to accommodate the experience of all languages, I'm skeptical. I can't imagine jupter preloading Revise in its julia notebooks, or catering to all languages similar to this trivial detail!

[RoyiAvital]

@janckerchen , My point was under the assumption Jupyter extension is already installed (Hence Python installation is implied).
What I'd like to happen is to have Julia LSP and Debugger. Besides that all I want is the Interactive Window experience.

Since the above basically requires zero effort yet adds features users seems to like, why not have it? The only step needed is the Julia community to tell MS it welcomes the Interactive Window experience on for Julia.
They have done most job, just ask them to enable it.

In the thread I linked, they did no enable it as @davidanthoff told them the Julia Extension wants to go the other path. The question is, why not both? I am not asking for more from the Julia Extension. It seems the allocated resources are small hence they can't digest more features. All I ask them is to ask MS to enable Julia in Interactive Window. It is that good experience. I'd argue it is better than the current Julia experience for casual work on code (Not package development).