I use jupyter to create lecture notes, and find the ability to
folding sections of the notebook based on section titles extremely useful.
Could such a capability be added to Pluto?
What do you mean by folding?
I think that's the idea like Collapse headings jupyter extensions.
Also interesting is hiding sections until an exercise is completed. (@dpsanders)
yes, I meant "Collapsible headings"
I think that's the idea like Collapse headings jupyter extensions.
Also interesting is hiding sections until an exercise is completed. (@dpsanders)
I would like something like that, this will make easy to write code encapsulated in collapsible blocks (say, modules of code). A further enhancement of this idea will be that, as order doesn't matter in Pluto, that we can reorder position of blocks of cells of code in the notebook, I mean to move 'freely' cells/blocks in the notebook. That is, why stick to the 'old style' of having the code as it would be a text when our minds doesn't work linearly if not instead disorderly (as a net)?
@Masacroso maybe notebooks within notebooks is interesting?
@Masacroso maybe notebooks within notebooks is interesting?
Certainly it seems interesting... it seems that you can fall inside an infinite nested sequence of notebooks!!! Yes, it seems that you can use something like this to separate the code in collapsible blocks.
Just to emphasize, the mechanism should be simple to use!
potentially A LOT of folds in a lecture:
step_1
etc
for a video lecture, I start with everything hidden,
then open a (subsection)
then reveal just a few lines at a time....
(Then record the lecture and edit the video.....)
A small file right next to each section would be great!
A collapses/expanded section would look something like:
Section 1 :arrow_right: and Section 1 :arrow_down:
Any suggestions on how to implement these collapsable feature?
This is quite tough, because headings are contained within cells, not the other way around, so we need to hide partial cells, and some of the inputs depending on the header structure of the output.
Sections don't make sense in the repl/script environment at all, hence shouldn't the sections be created by noop commands? What I mean is that the sectioning shouldn't be julia code, because then you are adding code to handle how the notebook looks. So the UI should have a "Add Section/Close Section" button, which adds some _noop_ code (such as a comment) to create the Section. My motivation is the same as that of demarcating cells as comments, instead of as extra julia code.
Naming Sections is also possible.
We can also add an activation command, like
!# Heading
!## Subheading
And so on, but that may be adding way too much extra parsing for us to do
Sections don't make sense in the repl/script environment at all
This sounds like searching for problems instead of solutions
馃槄 Yeah true. Idk, I just feel that UI elements/structuring should not affect code, especially if we aim to keep Pluto notebooks as simple .jl files which can be run in a scripting environment
I disagree, remember that md"# I am also a UI element (inside code)", TextField(default="and so am i"). Let's continue this discussion in another thread if you want to
Yeah, I agree with you.
But is the sectioning using code even possible? Unless, like you said we run through the outputs and re-render?
Can I suggest a bit more whacky idea? Can we have Cells within Cells? From a code point of view all cells could be top level, but only from a render point of view, they can be nested. Then the hiding and stuff has already been implemented.
Also, if we allow multilevel cells to have different levels, then we can strengthen the concept of one section being "complete" in itself.
This would basically be blurring the line between a notebook and a cell, and I think it's very similar to the notebook in notebook idea?
Can you clarify the difference from notebooks within notebooks?
I'm not sure I understand nb in nb that well, but I guess the main difference would be that (atleast in the example you gave), you don't HAVE to _call_ the inner notebook/cell.
If all the cells are flattened and simply brought to the upper level, then they'll run as if they're all just cells one below the other.
In the un-flattened case, I guess it would be very similar to the nb in nb.
One, you can edit an inner cell without running all the code in the outer cell. May work better for reactivity.
Two, you don't have to call a function to run it, it, it runs sequentially. I guess the inner cells can see everything in cells above them.
Most helpful comment
Also interesting is hiding sections until an exercise is completed. (@dpsanders)