Open fonsp opened 4 years ago
Variables could have a nice rectangular box with rounded corners
around them. The color of the box would depend on the section that the variable was defined in (section being determined by last markdown header).
Still not sure how to do this with CodeMirror, maybe you need to define your own mode
?
Highlighting depending cells won't work as nicely in a large notebook since most of the depending cells might be out of view.
I'm not sure anymore about solving this by a sort of birds view like I suggested in #116 . My impression from similar features in editors, where for example the scrollbar is a map of the code, is that it's clutters the UI more than it really helps.
Instead one could visualise a kind of weight of a cell based on the number of cells depending on it or maybe the estimated sum of execution time of all cells depending on it.
I'm not sure how to visualise the weight intuitively. Simplest would be a number in some corner giving the total execution time. This way you also get a simple profiling mechanic. Giving heavy cells a stony look and light cells a cloudy look is probably to childish/confusing :-).
I also like the idea from malyvsen to give sections or maybe areas of a notebook different (background?) colours, so you get an intuitive feeling where you are ("I'm currently in the blue section of my notebook"). In that theme, the weight of a cell could be visualised by a rainbow of the colours of depending cells. But that might again be hard to get right without becoming distracting or childish looking.
The stony/cloudy cells could be the same mechanism as the locking of cells fonsp mentioned in https://github.com/fonsp/Pluto.jl/issues/116#issuecomment-631121124
I love the idea of showing the weight of a cell visually!
Cells could also show a row of dots in the corner, each corresponding to a dependent cell. The radius/opacity of a dot can be the corresponding runtime (in log scale), the colour can be the corresponding section colour.
(No idea is too childish!)
The dots could be interpreted as a chain of different sized weights that the cell is dragging along. Each weight could be clickable to jump to the according depending cell.
I think it is quite important to have tools for visualizing dependencies, as the linear structure of a script is given up. I might be useful to think about the emerging collection of cells in a notebook more in the sense of a spreadsheet. So let us see what the spreadsheet guys have to offer:
https://help.libreoffice.org/6.4/en-US/text/scalc/01/06030000.html
IMHO not childish enough... But what comes out for me is that one needs visualization of both dependents and precedents.
I like the idea of a chain of weights. I think it would be nice to be able to filter a notebook to only show a cell and its dependents, too. You see these kinds of graphs quite a lot in disassembly software. E.g. in IDA Pro:
I don't think Pluto needs a graph, but moving the cells so that the whole chain is immediately above the dependent cell might be nice.
One way would be to write the execution order as a number next to each cell (similar to Jupyter), the cell numbers on which this cell directly depends on and the cell numbers dependent on each cell.
Example (needs to be made nice): [7] <- [1, 3, 6] (cells this cell depends on) -> [9, 12] (cells depending on this cell)
This is not as elaborated as some of the suggestions above, but could be easier to implement and would already give very valuable information for notebook debugging.
Some additions to @lungben 's proposal:
Does the current execution timer display total elapsed time including dependent cells? If not that would be a nice relatively simple (I'll presume) addition that provides probably the first-order information that one wants to know: If I was to make a change here just how long of a wait would I be in for?
Also, and apologies if this has been suggested somewhere already, I'm only kind of half-lurking on these issues and threads: One thing that might be helpful for both understanding the dependencies, and giving users something to do while they are waiting, would be to actually scroll to bring the currently-executing cell into focus. It might be a bit jarring as a default but maybe something like if you are not currently focused in a cell for editing, or maybe if you click the incrementing timer of the cell that triggered the updates.
As always I offer these ideas and largely know not what they'd cost to implement! 😊
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.