fonsp
VScode integration?
Now that Julia IDE dev support is switching from Atom to VScode, it would be amazing to see Pluto support in the Julia plugin or with VSCode Notebook 2.0.
@jmew
About turning Pluto into a VS Code extension: that would be an unexciting end to this experiment, https://github.com/fonsp/Pluto.jl/issues/158#issuecomment-640598768, and there are lots of reasons for a standalone notebook system to exist.
About other kinds of integration between the two: I had a very nice talk with @pfitzseb (from the JunoVSCode team) about this, we talked about VS Code recognizing the Pluto file format (to display it either in plaintext mode or notebook mode), sharing code for things like autocomplete, scope analysis and docs, embedding the Pluto editor inside a VS Code tab, and more. No concrete plans yet, but we are definitely interested!
I leave it to those more familiar than I, but what I had in mind was it would be great to:
- use VScode as an editor to edit Pluto files. This would get us multiple editors, code completion, hover help, linter, code navigation, keyboard shortcuts for manipulating cells, etc. which is otherwise time consuming to implement
- ability to see plots / other output in VScode (i.e. Notebook)
VS Code recognizing the Pluto file format (to display it either in plaintext mode or notebook mode), sharing code for things like autocomplete, scope analysis and docs, embedding the Pluto editor inside a VS Code tab, and more.
Yes, that's what I'm hoping for!
(I'd like to point out that Pluto already has all the features you mentioned (except a linter), but you are right that making them more advanced might be easier inside VS Code. Make sure that you update Pluto, and check the FAQ.)
Ah cool I didn't know about that documentation! Maybe add a link at top of README?
I meant to write "multiple cursors" rather than editors. Although I just discovered that ctrl-click gives multiple cursors, which is rad.
Since VSCode is basically a supercharged browser, can we not simply add the Pluto interface as a different tab? I for one love both VSCode and Pluto, and would love it if I could see it in one place. Also, because of the integrated shell, there's no pesky command line being open all the time. That way, it's a one time job to integrate Pluto.jl in VSCode, without adding a lot of code rewriting.
Yes, that's almost trivial to do. I'd kinda like to have tighter integration though, but that's a bigger project; might be worth doing the simple thing first.
I don't think that this adds much. If you really want to open it as a tab inside VS Code then you could use https://marketplace.visualstudio.com/items?itemName=zhhlwd.openTheWebPage
On the other hand, this would be very valuable if julia-vscode can automatically handle the built-in SSH forwarding for you, and take you straight to the proxy url.
Yeah, that's the big thing. AFAICT that should basically just work, as long as you actually have a local VSCode instance (so not in the browser via codespaces or code-server). Haven't played around with it though.
Oh no, I meant that instead of integrating the Pluto package into VSCode they way that jupyter notebooks are integrated, why not just open the normal Pluto interface into VSCode.
A new extension which checks if it is a Pluto NB or just a jl file will still be necessary. It'll also be awesome if the server can start by itself etc.
All the features that will be implemented for the VSCode version will eventually be implemented for Pluto anyway, such as Linting etc, because non-VSCode Pluto users will still want these features. So instead of integrating Pluto into VSCode, can we integrate @pfitzseb's work into Pluto? Then placing Pluto into VSCode for a single app for all kind of thing is simple.
Pluto is of reactive programming, Julia REPL is not. Both are very different in scripting style and purposes.
I think there's no need for integration.
@NaNotia nice to have VSCode text manipulation, ability to open library files that you may use in Pluto with Revise, minimap, unified settings / configuration, bookmarks, built-in terminal, plugins, .... that's a lot of functionality that would take a full-time team of 10+ people a couple years to create.
In order to facilitate users of other editors (e.g. Emacs/Vim), wouldn't it be possible to create/extend a/the Pluto (WYSIWYR) API? When I was looking a little into it, I found that e.g. when creating a code block in the browser notebook interface, the Pluto notebook's source file gets updated on the fly (which is immediately shown in the editor). It would be nice to make it possible to 'communicate' in the other direction also (from editor to Browser notebook).
Now, as an Emacs (i.e. Spacemacs) and org-babel user, I am used to evaluating code blocks. So now, it would be great if e.g. I could place my cursor on a "code block" in the notebook source file, and then tell Emacs to send an 'update' or 'evaluate' message for this code block to the Pluto server (sending the text to the code block with that ID). Of course, the Browser notebook interface should get updated to show the new/evaluated code block (we could work in a split the screen showing an editor window and a browser window. Although the notebook interface seems to work fine in a Webkit browser too, which can be embedded right inside Emacs). In the same way, we could send create and delete code block messages etc. Would something like this be possible? It would be really great.
(Instead of sending this message in the Pluto notebook's feedback field, I first went here to see if something like this has been proposed/is available already. Therefore, now I just provide this comment/feedback here)
I just want to give my two cents on Pluto and vscode: Currently I am using vscode in order to spell check my notebooks which is really nice. The downside is that I need to switch back and forth with a longer turnaround time. What vscode has and what Pluto is seriously lacking is a proper file browser when working with multiple files. So IMHO it would be very nice if one could
- open a Pluto.jl file in vscode both in source code and in regular mode
- make it possible to switch back and forth easily
Alternatively one could of course add things like file browsing and spell checking to Pluto directly but it is not clear to me if that would be more complicated since vscode is actually very good in that area.
@tknopp like this #1029 ?
yes this looks very nice! It basically solves the synchronization problem I have right now. An independent feature would now be the possibility of opening a Pluto notebook from within vscode. Ideally in a tab of vscode itself. Then it would not even be necessary to open the terminal, startup Julia, browse for the file.
I started working on an extension that runs and shows Pluto inside a panel (using a 'webview', i.e. iframe): https://github.com/JuliaComputing/pluto-vscode A cool thing here is that it forwards Pluto's assets and the websocket connection through VS Code, so it will also work on Remote SSH, GitHub Codespaces, JuliaHub, etc
For now, I am just building this as a way to power Pluto-based-apps (i.e. disabling editing), but if anyone with frontend experience wants to help, we could make sure that this extension integrates well with VS Code (e.g. use the VS Code file management instead of our file picker). Get in touch on the pluto dev zulip!
https://user-images.githubusercontent.com/6933510/134571646-cca5239a-1edf-48ab-b2a2-7828df79c002.mov
There is the second idea, using the Notebook API with a Pluto backend.
If someone is motivated to create and maintain it, I think that Pluto's communication model is in a stable enough state that we can make this work. Examples of using Pluto's frontend with a different backend are the JS backend (code) and the Julia WASM backend (code). Using the notebook API is the same, but reverse: Pluto's backend with a different frontend. Pluto's communication model design should make this relatively easy to implement.
Though this may need to be its own issue, having notebook support with Zed (the code editor) could be nice too. Although, the Julia notebook support in Zed is shaky as it is, so that might a while into the future.
