You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Provide an option to fold/collapse text within the actual body of the document. This could be a button to the left of each heading. (Currently, folding is an option within the sidebar, but changes here do not affect the appearance of the body.)
What problem does this feature solve?
This would help the reader/writer to more easily see the document's outline. It could also be useful during the writing process to help the writer focus on the section that they are working on.
This implementation may be in trouble because markdown does not have such syntax to support collapsing and expanding text?Or what rules do we use to collapse text?
How about rendering headings as being collapsible (as originally suggested)? It would just be a displayed property, no need to store such a state in the file itself.
Reacted by Sascha Brendel, Eerik Sven Puudist, Uvis Grinfelds, Dennis Weber, Yihan Li, EVA (Entity Value Attribute), b_l_a_n_q, anonymous133, Leon Mensch and Ľuboš Katrinec
I think that the original posting is asking for a way to scroll through the document with body text from only one section (or a few sections) shown at one time, and only headers for the other sections.
Of course this features seems possible, but the TOC feature already shows the header outline without body text, and allows the user to jump to a section. I'm not sure how many users would find this feature beneficial.
Another idea is an optional mode in which only the selected section would be shown in the edit buffer. Obviously the whole document still would remain in application memory. The other sections still would be shown in, and could be chosen in, the TOC.
How about rendering headings as being collapsible (as originally suggested)? It would just be a displayed property, no need to store such a state in the file itself.
I would also suggest to not only have headings collapsible but also codeblocks.
Background / Use case:
I'm writing documentations. Often I have quite long log outputs that I want to preserve (for example a nmap scan). Another usecase is for code snippets (50+ lines multiple times). This leads to a very long time spent on scrolling through the file for checks etc.
Reacted by EJ Makela, OuttaSpaceTime and anonymous133
Hello I want to participate to this issue. I think it's very counter intuitive to get this and it is very buggy.
Something like having a "collapsed text" in the @ menu would be good.
Also the render inside the <details> tag is wrong. It only support plain text but not the lists or any markdown syntax.
Also It happens often that the last </details> break, then the whole thing doesn't work anymore.
When it breaks, the code is perceived by MarkText as:
<details>
<summary>A title</summary>
</details>
the text that is supposed to be related to the details.
Instead of
<details>
<summary>A title</summary>
the text that is supposed to be related to the details.
</details>
this is a very weird bug.
But this is a very cool feature to get implemented into marktext fully. Because it's really unstable right now, it's very hard to use it inside MarkText.
This would be a very useful feature. It opens marktext for very large notes. Some people keep notes in a single file for easy searching. This kind of note files would have levels of headings, hence without folding/unfold they are impossible to work with. Emacs org-mode is suitable for this kind of job, with the option of opening the file folded to any level of headings of your choice by default. Of course, emacs can't render anything in-place so it would be wonderful to implement this in marktext.
@brainchild0 It seems all other editors have this feature, the ones I've used are emacs, atom, vscode, and Zettlr (also WYSIWYG). Folding on headings, and allow opening documents folded to the level of choice, helps a lot with productivity, imo.
@alexsong19: I am not rejecting the request, only asking whether it, as stated, or some alternative, best satisfies the underlying need, related to efficient document navigation.
Of the applications you have given as examples, only one is primarily an editor of text in natural language. The others are principally code editors, and naturally adapt the code-oriented metaphor of collapsible blocks toward general text. If they or Zettlr offer any compelling example of the requested feature, it may be considered. If the feature adds clutter to the visual field, then an option to disable it may be favorable to some users.
@brainchild0 I was suggesting the option of allowing folding on headings. Of course for those who don't need it, simply disable it in settings.
IMHO, I have not found an alternative to org-mode in managing notes of median to large size (say longer than 2 letter pages of equivalent content), precisely because of easy folding/unfold. Let me explain. The following features that org-mode allows are important in a workflow without interruptions, which I'd love to have in MarkText:
the ability to fold/unfold on headings within the editor
one-keystroke folding/unfold
allow opening files folded
"upholding" the folding status (explained toward the end of this comment)
This way, you can always very quickly get to the section you would like to work on. It allows you to very quickly navigate to different sections without moving your hands away from the keyboard
or moving your eyes away from the editor window.
An outline view on the side of the editor also helps but
it would take precious space
you need to move your hand away from the keyboard and use the mouse.
you need to switch your eyesight between the outline panel and the editor. After you click on a heading in the outline view, you need to move your eyes back to the editor and do a little searching to locate the heading in our current view.
There are basically two types of notes I think people write most frequently:
Type A is a few pages note on a specific topic, just like a scientific paper (rendering in-place is a killing feature here). For this, you don't folding on headings too much.
Type B is a larger note file, recording many small items, quick thoughts, questions, memos, one-liner knowledge. For this type, folding on headings is essential. Because note files like this are not meant to be read from top to bottom, line-by-line. It's a "library of books". In a file like this, some items are a few lines, some are more; if everything is expanded, that difference in the space each item take will affect your perception, because when you navigate up and down that space information is in your brain but is useless or even detrimental to your awareness of the global structure of the file. The workflow that makes the most sense would be that the first thing you see upon opening the file is the "catalog", i.e. all headings folded to a level of your choice, then you navigate and expand on the section you would like to read/work on, with ideally one-keystroke. Each section is organized in different levels of headings "equally", equal in the sense that the contents are hidden but only the title (heading) of the item is shown. Again the length of each note item doesn't matter and it shouldn't come into play when navigating through the file.
Org-mode takes a step further by "upholding" the folding status all the time. For example, when you search within a file folded, it will temporarily expand the section of the matched result, and when you navigate away it automatically gets folded again. This workflow helps one to maintain a very clear global structure in their minds. This is designed for a reason: nothing you do unintentionally would destroy the "folding" status of the file, so your mind and the file is always subconsciously synchronized. VScode, on the other hand, does not uphold the folding state, which basically renders it not useful. After a while of working in a big note file, many sections are expanded, only leaving some folded Heading not visible (because they only occupy one line now).
The only gripe about org-mode is of course it doesn't render in-place, which won't happen anytime soon if at all because of the way emacs were developed.
@alexsong19: I'm not sure I fully follow your suggestion, but it seems as though you are asking that when a document opens, it appears as a table of contents, without the body text, which would then appear for some specific section when the cursor moves over some particular header.
This feature is implemented well in other Markdown editors like Zettlr.
It's quite useful when you need to navigate among huge chunks of texts or when you have a lot of the sub-topics.
+1
I was looking for a open source markdown editor and this one came up often, and has 37.6k stars. The first thing I need is <details><summary>title</summary>collapsible content</details> and it's not supported..duh! I don't know if collapsible content is part of a markdown standard and if this editor only implements what's in the standard, but it should be added to both.
If the reason not to support it is that things are not visible without clicking them first, well, URL are supported and they are also not visible without clicking them first. GITHUB also supports collapsible content.
According to this, the future of this project is uncertain (also just look at the commit history and there's no other active branch).
If someone could code the support of collapsible content and add it to the Pull requests (I didn't see it there) that would certainly be appreciated by many and they, at least, could add/merge this feature themselves in the meantime.
Hi, I’d like to volunteer to implement section folding/collapsing for this issue.
My initial scope would be intentionally limited:
folding sections from headings in normal editing mode;
a matching experience in source code mode;
keeping search compatible by revealing or navigating to matches inside folded sections;
keeping copy/paste behavior safe so folding remains a UI state only;
deferring persistence of folded state to a later iteration;
deferring export and print support for folded sections in the first implementation.
For the UI, I’m imagining a small disclosure control in the heading gutter, similar to the screenshot above, with nested sections remaining visible under a collapsed parent heading.
I keep Foldable indented lists and Foldable codeblocks for latter implementation.
Does this scope sound acceptable before I start implementing it ?
Jocs, do you have any remarks or comments?
Activity
Jocs commentedon Feb 6, 2020
This implementation may be in trouble because markdown does not have such syntax to support collapsing and expanding text?Or what rules do we use to collapse text?
andersennl commentedon Feb 11, 2020
@ejm554 you mean something like this?
Click
This is hiddenIs this supported?
ejm554 commentedon Feb 11, 2020
Yes, I mean something like that.
Jocs commentedon Feb 16, 2020
@ejm554 Yes, it is supported by html block.
larabr commentedon Apr 7, 2020
How about rendering headings as being collapsible (as originally suggested)? It would just be a displayed property, no need to store such a state in the file itself.
brainchild0 commentedon Apr 10, 2020
I think that the original posting is asking for a way to scroll through the document with body text from only one section (or a few sections) shown at one time, and only headers for the other sections.
Of course this features seems possible, but the TOC feature already shows the header outline without body text, and allows the user to jump to a section. I'm not sure how many users would find this feature beneficial.
Another idea is an optional mode in which only the selected section would be shown in the edit buffer. Obviously the whole document still would remain in application memory. The other sections still would be shown in, and could be chosen in, the TOC.
Lednerb commentedon May 20, 2020
I would also suggest to not only have headings collapsible but also codeblocks.
Background / Use case:
I'm writing documentations. Often I have quite long log outputs that I want to preserve (for example a
nmapscan). Another usecase is for code snippets (50+ lines multiple times). This leads to a very long time spent on scrolling through the file for checks etc.jason-den commentedon Jul 16, 2020
It might be helpful to be able to collapse/expand any sub-content of a header (or sub-bullet-points base on indentation)?
Especially for long files like those awesome-collections, collapse/expand content would help you to keep the big picture in mind.
For example A simple jQuery Accordion with unlimited nesting
snowc0de commentedon Aug 18, 2020
Hello I want to participate to this issue. I think it's very counter intuitive to get this and it is very buggy.
Something like having a "collapsed text" in the @ menu would be good.
Also the render inside the
<details>tag is wrong. It only support plain text but not the lists or any markdown syntax.Also It happens often that the last
</details>break, then the whole thing doesn't work anymore.When it breaks, the code is perceived by MarkText as:
Instead of
this is a very weird bug.
But this is a very cool feature to get implemented into marktext fully. Because it's really unstable right now, it's very hard to use it inside MarkText.
alexysong commentedon Oct 13, 2020
This would be a very useful feature. It opens marktext for very large notes. Some people keep notes in a single file for easy searching. This kind of note files would have levels of headings, hence without folding/unfold they are impossible to work with. Emacs org-mode is suitable for this kind of job, with the option of opening the file folded to any level of headings of your choice by default. Of course, emacs can't render anything in-place so it would be wonderful to implement this in marktext.
alexysong commentedon Oct 15, 2020
@brainchild0 It seems all other editors have this feature, the ones I've used are emacs, atom, vscode, and Zettlr (also WYSIWYG). Folding on headings, and allow opening documents folded to the level of choice, helps a lot with productivity, imo.
brainchild0 commentedon Oct 15, 2020
@alexsong19: I am not rejecting the request, only asking whether it, as stated, or some alternative, best satisfies the underlying need, related to efficient document navigation.
Of the applications you have given as examples, only one is primarily an editor of text in natural language. The others are principally code editors, and naturally adapt the code-oriented metaphor of collapsible blocks toward general text. If they or Zettlr offer any compelling example of the requested feature, it may be considered. If the feature adds clutter to the visual field, then an option to disable it may be favorable to some users.
alexysong commentedon Nov 12, 2020
@brainchild0 I was suggesting the option of allowing folding on headings. Of course for those who don't need it, simply disable it in settings.
IMHO, I have not found an alternative to org-mode in managing notes of median to large size (say longer than 2 letter pages of equivalent content), precisely because of easy folding/unfold. Let me explain. The following features that org-mode allows are important in a workflow without interruptions, which I'd love to have in MarkText:
This way, you can always very quickly get to the section you would like to work on. It allows you to very quickly navigate to different sections
without moving your hands away from the keyboard
or
moving your eyes away from the editor window.
An outline view on the side of the editor also helps but
There are basically two types of notes I think people write most frequently:
Type A is a few pages note on a specific topic, just like a scientific paper (rendering in-place is a killing feature here). For this, you don't folding on headings too much.
Type B is a larger note file, recording many small items, quick thoughts, questions, memos, one-liner knowledge. For this type, folding on headings is essential. Because note files like this are not meant to be read from top to bottom, line-by-line. It's a "library of books". In a file like this, some items are a few lines, some are more; if everything is expanded, that difference in the space each item take will affect your perception, because when you navigate up and down that space information is in your brain but is useless or even detrimental to your awareness of the global structure of the file. The workflow that makes the most sense would be that the first thing you see upon opening the file is the "catalog", i.e. all headings folded to a level of your choice, then you navigate and expand on the section you would like to read/work on, with ideally one-keystroke. Each section is organized in different levels of headings "equally", equal in the sense that the contents are hidden but only the title (heading) of the item is shown. Again the length of each note item doesn't matter and it shouldn't come into play when navigating through the file.
Org-mode takes a step further by "upholding" the folding status all the time. For example, when you search within a file folded, it will temporarily expand the section of the matched result, and when you navigate away it automatically gets folded again. This workflow helps one to maintain a very clear global structure in their minds. This is designed for a reason: nothing you do unintentionally would destroy the "folding" status of the file, so your mind and the file is always subconsciously synchronized. VScode, on the other hand, does not uphold the folding state, which basically renders it not useful. After a while of working in a big note file, many sections are expanded, only leaving some folded Heading not visible (because they only occupy one line now).
The only gripe about org-mode is of course it doesn't render in-place, which won't happen anytime soon if at all because of the way emacs were developed.
brainchild0 commentedon Nov 12, 2020
@alexsong19: I'm not sure I fully follow your suggestion, but it seems as though you are asking that when a document opens, it appears as a table of contents, without the body text, which would then appear for some specific section when the cursor moves over some particular header.
Am I following?
20 remaining items
benvigano commentedon Jun 12, 2022
+1 - This is the only feature missing for me to switch to Marktext (best md editor btw)
pencilheart commentedon Jul 20, 2022
+1
Sometimes I use the feature to fold some code I've given up on, but if something goes wrong I check and re-use them.
MatveyM11 commentedon Aug 21, 2022
+1
This feature is implemented well in other Markdown editors like Zettlr.
It's quite useful when you need to navigate among huge chunks of texts or when you have a lot of the sub-topics.
hCKbJf6MCesgWSPH commentedon Dec 24, 2022
+1
I was looking for a open source markdown editor and this one came up often, and has 37.6k stars. The first thing I need is
<details><summary>title</summary>collapsible content</details>and it's not supported..duh! I don't know if collapsible content is part of a markdown standard and if this editor only implements what's in the standard, but it should be added to both.If the reason not to support it is that things are not visible without clicking them first, well, URL are supported and they are also not visible without clicking them first. GITHUB also supports collapsible content.
According to this, the future of this project is uncertain (also just look at the commit history and there's no other active branch).
If someone could code the support of collapsible content and add it to the
Pull requests(I didn't see it there) that would certainly be appreciated by many and they, at least, could add/merge this feature themselves in the meantime.player340 commentedon Apr 22, 2023
+1
This would be so useful!
geronimi73 commentedon Aug 7, 2023
+1
trongnghia203 commentedon Sep 13, 2023
+1
nikelborm commentedon Sep 13, 2023
@trongnghia203 @geronimi73 @player340 +1
luboss commentedon Feb 19, 2025
+1
Triple-Z commentedon Apr 18, 2025
+1
Tux69140 commentedon May 29, 2026
Hi, I’d like to volunteer to implement section folding/collapsing for this issue.
My initial scope would be intentionally limited:
For the UI, I’m imagining a small disclosure control in the heading gutter, similar to the screenshot above, with nested sections remaining visible under a collapsed parent heading.
I keep Foldable indented lists and Foldable codeblocks for latter implementation.
Does this scope sound acceptable before I start implementing it ?
Jocs, do you have any remarks or comments?
Blessings
Stephane
feat(muya): add heading fold/unfold in WYSIWYG editor
feat: foldable headings in the WYSIWYG editor (#1869) (#5276)
feat: foldable headings in the WYSIWYG editor (marktext#1869) (markte…