Comments (15)
I definitely appreciate that including all headers in a cell could lead to some complicated interactions with potential future features. Regardless of how that might be resolved, I would submit that including all headings in the TOC is simply the expected behavior, regardless of if they happen to be in the same cell.
from jupyterlab-toc.
Would it be possible to have an option to toggle this on/off?
from jupyterlab-toc.
from jupyterlab-toc.
I agree with the toggle feature.
A naive/ new user, I believe, will expect the table of contents to capture the full structure (headings/ sub-headings) of a document. Granted, going forward, document creators, knowing the limitation of jupyterlab's TOC, can design their document with the constraint of having headings/sub-headings broken out into their own cells. However, the naive assumption will fail for past notebooks that weren't designed this way.
I also recognize the desire for the collapse state from the TOC to propagate to what of the notebook is actually displayed as well (and the complexities this brings in the document model that kgryte mentioned above in #54 (comment)). In order to get the best of both worlds, I think a toggle would make sense -- toggled one way, all headings show up, with collapse-ability turned off. Toggled the other way, notebooks sections can be hidden by TOC, but any additional headings don't show up in TOC.
Granted, as a user that is not able to contribute to this feature request, I am fully appreciative of what has been done, what will be done, and design decisions made to simplify development :)
Thanks again for all the awesome work with jupyterlab and TOC! This is a great contribution to the world: π π π π
from jupyterlab-toc.
This change was actually intentional (though I am not sure that it is the right choice π). We would like to have new collapsing/expanding behavior also be allowed to apply to hiding/showing of cells (n.b., this is not implemented yet). Such behavior becomes very difficult to reason about once there are multiple headings in a single cell.
What are your thoughts on the issue? I was a bit uncomfortable about the change at the time...
from jupyterlab-toc.
I see your reasoning/ the direction you're going. I guess if I know that other headings within a cell will not be captured by TOC, it's not too big of an issue to make sure I split them -- the biggest issue for me now is that I have notebooks from before this change where it is currently harder to find some of my sections because the relevant headings are missing from TOC (but with time, I can switch to this new organization method).
One idea, if you want to capture every heading in TOC, but still allow for hiding specific cells -- perhaps don't allow hiding any cells in the notebook with more than one heading, and have documented that if one wants to collapse parts of these cells, users will have to split them (recovering the current behavior).
Also, how do you intend to handle hiding cells that have multiple headings in their output (as we talked about in #15?) Assuming you don't want to try to handle only showing some of the output based on what TOC entry is collapsed, I assume it's easiest if the first of such headings indicates it can be hidden, with none of the rest having that indicator. Then, toggling this first heading indicator will hide/show all remaining output with it. Does that sound reasonable?
from jupyterlab-toc.
I'm also interested in this, I have notebooks with a lot of markdown in a single markdown cell which currently only generates a single TOC entry, which makes it kind of useless π
from jupyterlab-toc.
What do you think about this @markellekelly? Should we restore the rendering of all markdown cells? I wasn't around for some of the design discussions you all had, so some additional insight would be useful...
from jupyterlab-toc.
@ian-r-rose I'm definitely open to including all markdown headings, but we should have a discussion of what exactly that would look like in the context of hiding cells. I think hiding the first header (or any header) of a markdown cell could make sense for hiding the entire cell - @ellisonbg might have some thoughts on this as well.
from jupyterlab-toc.
Love the new TOC features but it would indeed be great to include all markdown headings in a single cell in the TOC again, even if that means they cannot be collapsed. Specifically running into this problem in use cases where notebooks are automatically generated (e.g. from RMarkdown files or other plain text / non JSON formats) without clear delineation of cells so all continuous markdown is usually converted into a single cell.
from jupyterlab-toc.
It will definitely be more helpful to include all headings in a cell, just noticed the behaviour after pasting a long text.
from jupyterlab-toc.
If you consider re-enabling display of all headings, please also consider enabling it in programmatically generated HTML and Markdown (though that may be an automatic consequence of re-enabling this feature?)
I think there are a lot of use cases where displaying all programmatically generated headers is of great value! For example I often have to screen parameter combinations, for which I create one plot per combination. Creating a hierarchy of headings which I can browse with the TOC has been a great help in these situations. I realize that this is not trivial, but it would be awesome if you could enable this again! I think the ability to programmatically generate reports within the notebook really sets this environment apart from other alternatives.
from jupyterlab-toc.
The reality is that incorporating additional Markdown headings is hard to implement within the context of other ToC features, such as collapsing notebook sections, etc.
As mentioned above, but just to reiterate, once we incorporated support for collapsing notebook sections within a notebook and not just in the ToC, the presence of multiple headings in a single cell becomes very difficult to reason about, as this entails (a) that we'd impose a separate document structure independent of the underlying notebook structure (i.e., cells no longer serve as natural section boundaries), thus requiring a separate document model and model coordination and (b) that we'd have to manipulate cell contents (in a much more invasive way) in order to incorporate UI elements which we get for essentially free from the underlying notebook model. This is especially true for cells which output Markdown and HTML.
In short, from the perspective of a collapsible ToC, multiple headings within a single cell would impose a significant development burden and significantly increase extension complexity.
I think the reality is that, while it would be nice to support all features and possible use cases, this extension simply cannot. For particular use cases, such as report generation, other possibilities exist that allow you to still take advantage of the ToC extension. For example, instead of having a single notebook which both generates a report and includes that very report, one can programmatically generate a separate report notebook which can then be programmatically executed. (note that this also has the advantage of being able to create multiple independent artifacts for checkpointing, etc.)
In general, my recommendation is to follow a one heading-defined section per cell model, as such a model makes it considerably easier to reason about a notebook document.
from jupyterlab-toc.
One more thing I should probably point out -- personally, I don't think I care to have/ need sections of the document to show/be hidden based on TOC collapse state. However, I do appreciate the ability to have sections in the TOC collapse/fold, letting me hide away sections of the TOC that I'm not interested in at the moment.
So, I guess another sub-feature request as a part of the toggle -- decouple the TOC collapse state from the actual document state. So, in summary, I see these two toggle states:
- Show all section headings/subheadings, but don't allow sections of the document to be hidden based on TOC section folding. However, do allow sections of the TOC to be hidden (especially helpful when I have a large number of programmatically generated TOC headings).
- Show only collapse-able section headings (basically, top-line headings within a cell), but allow folding these in TOC to trigger the show/hide state of the cell in the document itself.
I hope that was clear! Also, I think some of the TOC folding is already implemented, but I'm not in front of jupyterlab at the moment, so I can't confirm ...
from jupyterlab-toc.
Something about this issue? I will appreciate the ability to display ALL headings in a cell too as in the classic Jupyter Notebook. Maybe as an option if there are features where those texts will be annoying.
from jupyterlab-toc.
Related Issues (20)
- Big wasted space HOT 2
- Falied to install jupterlab-toc HOT 2
- Allow heading numbering to start counting at later Headings and not just Heading 1 HOT 2
- Render cell doesn't show. Jupiter lab 2.2.6 HOT 1
- configuration option for font size HOT 1
- .py file navigation: remove method/class arguments
- Bring focus to
- Side bar is not showing up HOT 1
- An error occurred installing @jupyterlab/toc-extension. HOT 19
- Error while installing @jupyterlab/toc
- Mark this repo as archived HOT 10
- TOC eats up code cells HOT 1
- How to install if I cannot run "jupyter" HOT 4
- Indents for contents HOT 1
- The collapse ticker is missing in the table of contents HOT 1
- provide a new outline of folding , not adaptive but directly masking the titles when it is shrinked
- Keyboard shortcut to show sidebar panel? HOT 1
- An error occurred installingΒ @jupyterlab/toc-extension. HOT 4
- No table of content in jupyter lab 3.0.7 HOT 4
- '@jupyterlab/toc' is not a valid extension HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jupyterlab-toc.