# Support collapsible hierarchy of sections #2275

Open
opened this issue May 25, 2017 · 19 comments

Contributor

### scottdraves commented May 25, 2017

 Allow users to toggle open/close sections by clicking on some kind of UI element. This helps with navigating and organizing large notebooks.
Contributor

### sccolbert commented May 25, 2017

 Related issues: #1742 #713

### afshin added this to the Future milestone May 25, 2017

Contributor Author

### scottdraves commented May 26, 2017

 This might mean more integrated support for sections. Right now, afaik the only way to make them is to create a markdown cell and then type "#". This maybe hard to discover, and also makes them hard to build GUI around them (since they are in the middle of cells). Should sections be their own cell type?
Contributor

### ellisonbg commented May 28, 2017

 The original version of the ipython notebook did have heading cells. However, over time we found that users were just typing headings using markdown. Because of that, we changed the notebook format to remove the heading cells. After seeing how it worked both ways, I think it was a good decision. However, our current approach is completely compatible with offering sectioning. Here is the rough idea: * A separate plugin that would watch a notebook model. * On change, it would scan the cells, and find markdown cells that begin with a MD heading (one or more #). * It would then infer the "virtual" sections by looking at those headings. * We can build a side panel UI that presents those virtual sections in a useful manner. It shouldn't be too difficult to build that... … On Fri, May 26, 2017 at 11:10 AM, Scott Draves ***@***.***> wrote: This might mean more integrated support for sections. Right now, afaik the only way to make them is to create a markdown cell and then type "#". This maybe hard to discover, and also makes them hard to build GUI around them (since they are in the middle of cells). Should sections be their own cell type? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2275 (comment)>, or mute the thread . -- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com
Contributor Author

### scottdraves commented May 29, 2017 • edited

 totally agree on keeping the data model the same and building improved UI around it (the virtual sections).
Contributor Author

### scottdraves commented May 29, 2017

 Is there an issue already filed for making the markdown editor more GUI, either with a toolbar like github's, or a full on WYSIWYG editor? Isn't there an effort to make this pluggable and Maybe that's where this gui lives?

Contributor

### ellisonbg commented Aug 17, 2017

 Ran into a need for this working with some large notebooks recently. Would really help a lot.
referenced this issue Oct 5, 2017

### aquirdTurtle commented Oct 10, 2017

 This is a really important feature for me. In my lab, we use a single notebook to organize all the data & notes that we collect over the course of a day, and by the end of each day the notebook is quite large. Notebook organization is important enough that I probably need to stick with the plain notebook + the nb_extensions collapsible headers extension until collapsible headers or a TOC is supported in Jupyter lab. Really excited for Jupyter lab though!

### pluviosilla commented Jan 24, 2018 • edited

 I find the NB Extensions feature that allows a TOC on the lefthand side invaluable with large notebooks, and all my notebooks tend to get large, because of the way I use this marvelous tool. Unfortunately, after the classic notebook reaches a certain size it starts to time out when loading the Javascript for NB Extensions and MathJax. I am extremely eager to find out whether JupyterLab will offer the same functionality and fix the timing out problem. This image of the TOC supplied by NB Extensions shows how it makes a complex document much more accessible. My fear is that Jupyterlab developers will be too focused on producing an IDE with lots of new features and that you might sacrifice the qualities of Jupyter that make it suitable for turning programs into documents. I'd rather you focus on getting current features to work better, especially document publishing features that tend to falter as documents grow.

### jsmm commented Feb 24, 2018

 There is no way I can orderly write nor browse large notebooks without table of contents. I am also waiting for TOC2 to be ported before moving from Jupyter notebook to lab.
Contributor

### jasongrout commented Feb 24, 2018 • edited

 My fear is that Jupyterlab developers will be too focused on producing an IDE with lots of new features and that you might sacrifice the qualities of Jupyter that make it suitable for turning programs into documents. I'd rather you focus on getting current features to work better, especially document publishing features that tend to falter as documents grow. I think that the largest part of our time is spent on making a rock-solid extensible underlying framework so that people can explore this and many other ideas and workflows with extensions. For example, @ian-r-rose is experimenting right now with building a TOC extension: #3949
Contributor

### ellisonbg commented Feb 24, 2018

 We would be foolish to try to compete with traditional IDEs - we remain focused on interactive computing and computational narratives. … On Sat, Feb 24, 2018 at 9:10 AM, Jason Grout ***@***.***> wrote: My fear is that Jupyterlab developers will be too focused on producing an IDE with lots of new features and that you might sacrifice the qualities of Jupyter that make it suitable for turning programs into documents. I'd rather you focus on getting current features to work better, especially document publishing features that tend to falter as documents grow. I think that the largest part of our time by far is spent on making a rock-solid extensible underlying framework so that people can explore this and many other ideas and workflows with extensions. For example, @ian-r-rose is experimenting right now with building a TOC extension: #3949 <#3949> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2275 (comment)>, or mute the thread . -- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

### riemannzetagambit commented Aug 24, 2018

 Are there any branches that are working on this? I'd like to contribute if I can-- I know a number of folks who haven't transitioned over from plain notebooks because of the lack of this feature. I love the other features of jupyterlab too much now to not use it but it's a real pain on any notebook of substance to navigate without collapsible headings.
Contributor

### ellisonbg commented Aug 25, 2018

 We are working on a new table of contents extension that will have that feature here: https://github.com/jupyterlab/jupyterlab-toc We are not quite there yet, but things have been moving quickly ;-) on this extension … On Fri, Aug 24, 2018 at 1:48 PM David Stone ***@***.***> wrote: Are there any branches that are working on this? I'd like to contribute if I can-- I know a number of folks who haven't transitioned over from plain notebooks because of the lack of this feature. I love the other features of jupyterlab too much now to not use it but it's a real pain on any notebook of substance to navigate without collapsible headings. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2275 (comment)>, or mute the thread . -- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

### marius311 commented Aug 28, 2018

 @ellisonbg Thanks for you guys' work on that, I'm very happy to hear collapsable headers are on the way via that extension, since at the moment its the main drawback of Jupyterlab for me. As a general point though, as stated above, the question of whether sections/headings within the notebook are collapsible is separate from where the TOC knows about it or can trigger it, right? One could imagine the notebook itself allows collapsible sections independent of TOC behavior, such as how the collapsible_headings plugin works for Jupyter notebook.
Contributor

### ellisonbg commented Aug 29, 2018

 Yep, very true that the notebook can have collapsible sections without the TOC - although right now the TOC extension is where all the logic for computing the inferred hierarchy of nested sections is located. One reason for that is that we are building out the TOC to work with lots of different files types. But this will likely evolve to enabling this type of collapsing in the documents themselves in some manner. … On Tue, Aug 28, 2018 at 10:50 AM Marius Millea ***@***.***> wrote: @ellisonbg Thanks for you guys' work on that, I'm very happy to hear collapsable headers are on the way via that extension, since at the moment its the main drawback of Jupyterlab for me. As a general point though, as stated above, the question of whether sections/headings within the notebook are collapsible is separate from where the TOC knows about it or can trigger it, right? One could imagine the notebook itself allows collapsible sections independent of TOC behavior, such as how the collapsible_headings plugin works for Jupyter notebook. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2275 (comment)>, or mute the thread . -- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com

### pluviosilla commented Aug 29, 2018

 I’d like to chime in with another blue skies scenario feature wish list with regard to TOCs. J When the dust settles on TOC development and the collapsible hierarchy in particular, I sincerely hope that its default behavior will **not** be for the entire Tree View to expand every single time one does an edit, the way it does in Jupyter notebooks. I find that behavior to be extremely annoying. From: Brian E. Granger [mailto:notifications@github.com] Sent: Wednesday, August 29, 2018 2:16 PM To: jupyterlab/jupyterlab Cc: John Strong; Comment Subject: Re: [jupyterlab/jupyterlab] Support collapsible hierarchy of sections (#2275) Yep, very true that the notebook can have collapsible sections without the TOC - although right now the TOC extension is where all the logic for computing the inferred hierarchy of nested sections is located. One reason for that is that we are building out the TOC to work with lots of different files types. But this will likely evolve to enabling this type of collapsing in the documents themselves in some manner. … On Tue, Aug 28, 2018 at 10:50 AM Marius Millea ***@***.***> wrote: @ellisonbg Thanks for you guys' work on that, I'm very happy to hear collapsable headers are on the way via that extension, since at the moment its the main drawback of Jupyterlab for me. As a general point though, as stated above, the question of whether sections/headings within the notebook are collapsible is separate from where the TOC knows about it or can trigger it, right? One could imagine the notebook itself allows collapsible sections independent of TOC behavior, such as how the collapsible_headings plugin works for Jupyter notebook. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2275 (comment)>, or mute the thread . -- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub bgranger@calpoly.edu and ellisonbg@gmail.com — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2275 (comment)> , or mute the thread .

### watkinrt commented Jun 3, 2019

 Like a couple other comments, the lack of collapsible headings has prevented me from fully switching over to JupyterLab; it is just too hard to manage large documents (even with the TOC extension). For that reason, I started developing a collapsible heading extension based on original notebook extension. I don't want to replicate work if the developers of the TOC extension are going to implement the same feature (especially since they area to be much more sophisticated developers than me), but with no roadmap or timeline, I also don't want to wait around for its development. I posted a comment on the JupyterLab discussion board regarding development suggestions for this feature, but it looks like this might be a better place to get feedback. As I stated earlier, I'm just trying to transition the original notebook extension to JupyterLab's framework; however, it isn’t always clear to me how to handle this transition. I’ve been able to implement methods to identify header cells and to manipulate metadata, but actually implementing the collapse philosophy is a little lost on me. The original extension directly manipulates the javascript to incorporate event handling, css modifications, etc, which seems to be what JupyterLab is trying to get away from (although I can't say I fully understand the JupyterLab framework). I took a look into the input/output cell collapse functionality build into JupyterLab, but haven’t figured out how to translate that into manipulating groups of cells denoted by headings. Anyone have any thoughts on the best way to approach this?

### aquirdTurtle commented Jul 29, 2019

 I got a little tired of waiting, so I took the weekend to take a shot at implementing my own collapsible headings extension. The very early version of this is located here. I think the basic collapse functionality is working well, but the UI still leaves a lot to be desired. I haven't figured out how to properly add some sort of clickable widget next to the markdown headers like in the original, so right now you can only collapse the currently selected header with a hotkey (ctrl Q). Any advice on how to add such a ui element to the cells in addition would be very useful. This is simultaneously my first attempt at a Jupyterlab extension, as well as my first foray into anything java/typescript or any sort of web-application, so I'm sure the implementation could be better as well. Feedback is very welcome.
referenced this issue Jul 29, 2019
referenced this issue Jul 30, 2019