Would be very cool if this is done within the reactive environment! I imagine:

there is a yellow cell, before all other cells (which is hidden by default), and whatever the output of that cell is will be used as config Dict by Saturn. Like:

Dict(:interactivearrays => false, 
     :theme => "body: {font-family: 'Comic Sans MS' !important;}")

Something very cool is that this cell can also be reactive! Like:

if @__FILE__ == "bigdata.jl"
    Dict(:theme => read("~/bigdatatheme.css", String))
else
    Dict()
end

Needs a config file

The input

arr = [1,2,3]
(a,b...) = arr

outputs the syntax error

- ERROR: syntax: invalid assignment location "b..."
Stacktrace:
 [1] top-level scope at REPL[4]:1

in the Julia REPL, but when ran in Pluto causes the notebook cell to get stuck loading indefinitely & never displays an error:

Currently, function definitions are considered dependent on the variables and functions that are referenced in them, and function calls are considered dependent on definitions.
This breaks when a() calls b(), and b() calls a() - even though this double recursion is not paradigmatically illegal.

We should instead consider function calls dependent on the variables and functions referenced in the function definition. This will also solve the problem of reactivity in response to modifying global variables within functions.

We could use Juno's Ink, or fork Observablehq's inspector.

See below

Suggestion:
When focused on a cell, all cells that reference that cell get highlighted. (Either with depth 1, or with full depth.) This makes it easy to see what reevaluating the cell will do.

Vice versa might also be useful.

If a Module exports some variables, those will be brought into the workspace when a using Module call is somewhere, and they will disappear when the using call is gone.

However, removing a using Module does not reactively reevaluate cells that depend on its exported variables. Those cells need manual reevalutaion.

Requires Pluto to know exports.

Decide which ones to support, and nudge users of other browsers to switch to firefox.

One of the reasons to write a notebook system from scratch is to change the default file format. Our wishes are:

• Output is saved separately, optionally.
• The file has nothing but legal Julia syntax.
• The file must be readable in plain form.
• Notebooks are git merge-friendly. This includes:
  • Minimal changes in code are minimal diffs.
  • A merge conflict where two people added a cell can be merged automatically.
• The file should not change when you:
  • Open the file, run cells, save and close the file.
• If your notebook runs without errors on "Run all", it should run when you do julia mynotebook.jl
  • You should be able to include("./yournotebook.jl") in another script/notebook, and use the globally defined variables and functions.
  • This creates a problem with arbitrary cell order.
• Cells that are disconnected dependency-wise, should keep their order.
• Any legal Julia script can be interpreted as a Pluto notebook.

Single access tokens or password or ?

The current timing includes the round-trip of expression and result.

To recreate:
add two cells with

x = 1

x = 2

then change one of the cells to

x

and evaluate

(note the empty error message)

evaluating the cell x a second time (without change) gives:

Evaluating the cell x = 1 fixes all errors.

Or a simple try/catch around the eval!

Also: let's add Markdown as a standard import.

A way to change the path of a running notebook.

I suggest that this will move the file, not copy it.

Needs to report to the user whether the path is legal, and prompt whether they want to override.

Right now the client can send requests to Pluto:
send("completepath", {query: "/home/f"})

The server will quickly respond, and the response message is handled by editor.js/onUpdate. However, it would be nicer if the control flow was not lost, and you could do:

sendreceive("completepath", {
    query: "/home/f",
}).then((update) => {
   ...
}).catch(console.error)

To do so, requests just need a unique ID, and client.js can handle all the Promises.

If #8 is done then this would be much easier!

A cell input like:

🍕 = 1
🥞 = 2

should not be legal, because it is not a single expression. This might be unexpected (and part of the learning curve) for new users, and we could accept it without breaking the paradigm by:

• Splitting up the expression into two cells.
• Giving the cell two outputs, which are stacked on top of each other with a clear division between them.

A nice hybrid solution is to do the first option, and to design the editor layout in such a way that all cells fluently follow each other. (If code is folded).

Note:
The cell

🍕 = 1; 🥞 = 2

which is syntactic sugar for

begin
    🍕 = 1
    🥞 = 2
end

is a single expression, which is not an assignment, but an evaluation that performs two global assignments. Parsing this cell should be legal (as a single expression), but running it might give an error (depending on what we decide to do with globals).

Not a biggie though

What to do with fonts? Custom themes? Licenses?

Related and also nice: ability to execute second block if it does not depend on any running blocks.

This way it could be used in other projects! In any case, it's nice to separate the reactivity core from the HTTP server.

It looks like StaticLint.jl does the same as src/react/ExploreExpression.jl, with additional features.

Give code timings by default, click on it to benchmark that cell.

Because of the moving workspaces, you have to use import instead of using. Also, all workspaces live inside Pluto.ModuleManager, so they can't use packages that you added to your environment. (Pluto has its environment separate from the one you started the REPL in.)

Things exported by a package, from using, don't show up in names:

julia> using Plots

julia> plot
plot (generic function with 3 methods)

julia> names(@__MODULE__, all=true, imported=true)
9-element Array{Symbol,1}:
 Symbol("##1#2")
 :Base
 :Core
 :InteractiveUtils
 :Main
 :Plots
 :ans
 :eval
 :include

We almost have it already, but we still need:

• List of running notebooks in UI
• A way to stop a running notebook
• A separate workspace module for each notebook

By fetching Project.toml from jsDelivr.

With a link from the Pluto page.

Let's do Github Pages for now without Documenter.jl? The documentation is mostly about using the UI, not about interfacing with Pluto from another julia program.

Right now we have a text input box where you can paste the full path of your notebook file. Instead, we should have a file browser inside the web interface.

The ideal solution would be the built-in "Open file" dialog, but browser security prevents us from getting the path of the selected file, which we need for autosave.

This means that we need to implement a WebSocket response for file queries, and design UI to browse files (no usable solution exists for this yet).

A way to define a cell like:

t = Saturn.animated(5fps, :loop, 1:100)

Restarts when (reactively) reevaluated.

but what about multiple animators in one notebook? using the same fps for all makes sense.

Jupyter can't stop everything, but the REPL can. Let's try to make it like the REPL!

When executing a cell, Pluto should wait for a running cells to complete.

Let's do this thing!

CodeMirror side - options:

• show-hint.js
• DIY

Julia side - options:

• look at how the REPL does it - lightweight option
• integrate the microsoft Language Server Protocol (used by VS Code, Atom and some others) - feature complete option
• run the LSP implementation from Juno or VS Code without using the LSP - maybe the easier option

Exporting: export to markdown (another TODO item), then use Literate.jl.
Importing: not sure how to preserve Jupyter's markdown cells, might need to parse the notebook file.

But:

• should we add these dependencies to our package?
• cell order should be topological for jupyter. What to do with markdown cells?

EDIT

I made a web app to convert Pluto.jl notebooks ⇆ Jupyter notebooks:

https://observablehq.com/@olivier_plas/pluto-jl-jupyter-conversion

I've seen this a few times - when I leave Pluto running overnight, and put my computer in hibernate (i think?), the WebSocket communication is broken.

On the client side:
HTTP requests work fine. Opening a new notebook (with new UUID) still works.
The socket is openened, but no messages are received. I can send (bad) messages without closing the socket.

On the server side:
There are no errors in Pluto, not even for bad messages or closing the socket. Last night's sockets closed, and this error was thrown in Pluto.jl:457.

system: Windows 10, pluto running on Julia v1.0 in Legacy WSL Ubuntu 18

In the following notebook:
y = 1
f(x) = x + y
g = f
g(2) gives 3

Changing y = 1 to y = 2 does not update the output of g.

Ability to export to HTML that has all @bond interactions baked. The output for each combination of inputs will be stored inside the document, in an efficient way.

This way, you would have an interactive document that works offline, without a running Julia instance.

Multiple defintions for a variable should be illegal, but writing different specialised versions of the same function - in different cells - should be legal.

For now, the multiple def error for functions should advise the user to put all function defs in the same cell, inside a begin block.

Like a slower/stationary traffic light for queued cells.

Insteaf of "unexpected ... after expression", it should detect that the cell contains multiple valid expressions, and advise the user to wrap cells in a begin/let block.

Or we solve #7 - multiple outputs per cell.