Pluto's .jl files and cell delimiters (convergence with Juno/other IDEs)

[fbanning]

I've been playing around with Pluto today and had a look at the raw .jl files it creates in a text editor. First of all I want to mention that I really (!) like Pluto's approach of creating standard .jl files instead of introducing another file format (I'm looking at you, Jupyter notebooks...). Collaboration in teams should not rely on the tools and/or IDEs we use. It's the contents of the files that are important and making these accessible to everyone is crucial (no matter their choice on how to display the files).

Now as I was skimming through the .jl files generated by Pluto, I had a few thoughts that I'd like to propose here:

• It would be great to use the same cell delimiters in Pluto as in Juno. Juno is very likely one of the most used IDEs for Julia and it might be a good idea to be oriented towards compatibility with it.
  As per default, Juno uses ##\s, #--- and #\s?%% (in an upcoming version ##\s will be replaced by ##(?!#) to allow for more flexibility).
  In contrast, Pluto currently uses # ╔═╡ as cell delimiters. This is not recognised as a new cell in Juno by default (a new rule would need to be added for this).
  Now my proposal would be to simply change Pluto's standard cell delimiter to be ## ╔═╡ instead. Quick and easy fix to allow for higher convergence and intercompatibility between development environments. What do you think about it? Any reasons not do so?

• Pluto adds two lines to the beginning of the file:

### A Pluto.jl notebook ###
# v0.9.2

I would suggest that this section gets moved to the end of the file, right before where the cell order is located:

# ╔═╡ Cell order:
# ╠═Blablabla
# ╠═Blablabla

This might help to keep the actual code section relatively "clean" from any text generated by Pluto (besides of the unique cell IDs after each cell delimiter) and also makes it clear to non-Pluto users that the following section is Pluto related and should not be modified.

Looking forward to hear what you think about these two suggestions. :-)

[fonsp]

Thanks for your suggestions! We had not thought about compatibility with Juno.

First of all, I should say that we want to avoid any change to the file format, since this would mean adding conversion code to handle old files written before the format change - making the project harder to maintain.

It does feel nice to have Pluto's format be compatible with Juno's, but I think that this would only lead to confusing use cases. The file format looks simple (because there is not much to store besides code), but it is not intended to be written in a text editor. Doing so would simply be too error-prone, but more importantly, the Pluto project is about creating a new IDE, not about a new file format for traditional IDEs. There are fundamental differences between the editor experience in Pluto and that inside a linear text editor, which is why we felt that we needed to create a new IDE.

Another problem is that text-editor-friendly compatibility with Juno requires more than just changing the cell delimiter. It also means a variable number of newlines before cell delimiters, dynamic handling of code before the first cell delimiter, smooth conversion of non-pluto notebooks to pluto notebooks, and probably more.

Perhaps I am making some wrong assumptions - why do you think that it would be useful for Pluto's file format to be compatible with Juno? Specifically - what kind of workflow would benefit?

About suggestion 2: while ### A Pluto.jl notebook ### is a Julia comment, it is also the file's header, i.e. the first sequence of bytes you get when reading the file. This is standard practice for file formats, and it means that programs (including Pluto) can easily identify this file as a Pluto notebook.