Option to fold/collapse text #1869
Comments
|
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? |
|
@ejm554 you mean something like this? ClickThis is hiddenIs this supported? |
Yes, I mean something like that. |
|
@ejm554 Yes, it is supported by html block. |
|
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 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. |
I would also suggest to not only have headings collapsible but also codeblocks. Background / Use case: |
|
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 |
|
Hello I want to participate to this issue. I think it's very counter intuitive to get this and it is very buggy. 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. |
|
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:
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 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. |
|
@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? |
|
I was asking for the ability to fold/unfold, the option to open files folded to the level of headings to your choice, and the editor uphold the folding status. I've edited my post to make it more clear - am I making more sense now? |
I believe that this detail has been clear from the beginning, but what remains unresolved for me is the question of what are the compelling use cases. Yes, the current functionality offers no support for a document view that shows only headers, but this view is precisely the purpose of a table of contents, and I have yet to understand a use case which makes it important that this view appear in the main document pain rather than the auxiliary one in the side bar. |
|
One use case would be the paragraph about Type B notes in my previous comments. The ToC on the side, as I've also mentioned above, has three drawbacks:
To be able to conveniently fold/unfold on headings, endow you an uninterrupted workflow, in a relatively large note file. I detailed this as best as I could in the lengthy comment above. |
Yes I agree that these drawbacks are real, but I believe that the important question is whether they limit some common or important use case. That is, in what real-world scenario is moving the hand to the mouse from the keyboard, or switching eyesight between two panels, a serious obstacle? Also note that keyboard shortcuts might readily be added to support navigation of the table of contents, without displaying sections as folded. |
Are you serious? In what real-world scenario does a function requiring |
|
As @alexsong19 mentioned, if a document is very long I often find myself wanting to hide most of the stuff to focus on specific sections. I think this is a fairly common use case when you are dealing with notes that cover multiple topics and are somewhat scattered. |
It's inconvenient, but inevitable, generally. The question is whether and how reducing this particular inconvenience enhances the usability of the application for users broadly. Nothing I've written is meant to argue that the feature is a bad idea, but I am still trying to understand in what way it might be considered a serious improvement. |
Would it help simply to add keyboard commands to jump to the preceding or succeeding sections? |
|
As @alexsong19 commented, an editor without efficient folding capabilities is useless for structured notes in one long file. I still edit my notes with vim in plain text mostly because it has a decent folding system, although I miss many modern features (there are also many other modern features that I don't miss). @brainchild0 Since you are asking for a real use case, here is mine: one of my longest note files contains all notes that I keep on macOS, like system installations, system configuration, software installations and configuration, short usage guides, problems and fixes, etc. This file has been evolved over several years, and it currently contains 19,000 lines and 1,700 folds nested in up to 5 levels. The top-level contains 20 folds, one of the longest folds contains 260 immediate sub-folds (in this particular fold they are sorted alphabetically, otherwise manual search is difficult). Each fold contains one line for the open marker ("{{{" in vim) and header, and one line for the close marker ("}}}"). The fold header contains a type symbol (* for info, + for done, - for todo, etc.), a date, and a title. Without folds it would be simply impossible to edit this file multiple times (order of hundreds or thousand) and efficiently, which means to go very fast where I want to add/modify content (a search sometimes works, but most of the times I need to go through the headers and open a few levels in order to find the correct place), to move a fold (including all its sub-folds) to another place, and to rearrange the structure quickly and without the need to calculate the level of each header. I would switch immediately to any markdown editor if it had decent support for (in order of preference): folds, temporary split screen in order to see/edit two different parts of the file at the same time, either efficient builtin or programmable key bindings, efficient search with regular expressions (in vim with a single keystroke I can go to the next occurrence of the word under the cursor), either simple or configurable layout (in order to remove all fancy and useless decorations - marktext is perfect in this respect). To make it simpler: no fold support, no switch to a markdown editor for me. Answers to expected questions Q: Why don't I split a very long file into many small files? Q: Why am I stuck with vim and I don't try a markdown editor? |
|
@georgeef: Sorry, I am missing a few details about your use case. What is the usage of three consecutive squiggly braces, and what is the meaning of the term folds, in your example? It seems you are not referring to section (as separated by section headers). |
|
@brainchild0: I assume that a section in markdown syntax is defined as a header of any level and all the content after it, up to (not including) the next header of the same or smaller level (or the end of the file). The level of a header (and its corresponding section) is the number of #s. A section can contain lower-level sections (upper level means smaller level number, lower level means bigger level number). With the above definitions, a fold in vim is practically the same thing as a section in markdown syntax (there is a small difference, see below). For example the following markdown text: ` ## section 1.1 ### section 1.1.1 ## section 1.2 # section 2 is equivalent to the following fold-aware text [edit: in vim]: ` {{{ section 1.1 {{{ section 1.1.1 }}} }}} It is often convenient to have text between two folds of the same level, e.g., say that I insert an empty line above "section 2" in the fold-aware text, such that there is a separation between"section 1" and "section 2" when they are both collapsed. Adding another empty line above "section 2" in the markdown text does not help, since it will be eaten by "section 1.2". One possible workaround would be to insert an empty header of level 1 (just a # without header text) followed by an empty line immediately above "section 2". This empty header would act as a fold end for the current section of level 1, but it would not render anything because it is empty. The simplest implementation would be to provide folding capabilities to headers, as suggested by @ejm554. This is not the same as the The TOC is not practical for very long files. In my use case the fully expanded TOC would be 1,700 lines, so it takes some considerable effort to navigate through it, and spending this effort in a separate view is destructing and inefficient, as already commented by others. What I would need is an easy way to expand/collapse headers in the main view, and a simple visual guide in order to easily distinguish which headers are expanded and which are collapsed. The fold state could be implemented with one of the following options (ordered from minimal to full-featured):
[S3] and [S4] deviate from the markdown syntax, since they introduce special attributes recognizable only by one editor (all other editors/viewers will ignore these attributes and will show the file with all headers expanded). The
All the above make a decent fold-aware viewer, but more is needed for a decent fold-aware editor:
The folding mode is only an editor convenience, at the end the file is saved in standard markdown syntax. |
@georgeef: Using this analogy has really made me confused. The application is a Markdown editor. Are you discussing a case of editing a source document not formatted in Markdown? |
|
@brainchild0: as I said in my first message, I currently use vim to edit my notes. The second snippet shows how my notes appear in vim. The first snippet shows how they would be translated to markdown syntax. The vim snippet shows more clearly the concept of folds, but with a more verbose syntax. |
@georgeef: I'm still missing important details of your use case. What is being translated to Markdown syntax? In what format is your file saved? |
|
@brainchild0: I don't use markdown for now (for the reasons explained in my first message), so my file is in vim syntax (second snippet) and nothing is translated. If I wanted to convert my notes to markdown, the patterns in the two snippets show how one syntax translates to the other. It doesn't matter how I would do the translation. I am not suggesting in any way that marktext should process any other syntax than markdown. The point is if marktext could support some of the folding functionality (that I now use with vim), with files saved in pure markdown syntax. Also it doesn't matter what is the editor's internal representation of the folding structure (derived from the markdown headers), as long as it reads and saves files in markdown syntax. |
|
@georgeef: Yes, I do understand that nesting and folding is an abstraction that generalizes across languages, but it may be helpful in this discussion to keep the examples concrete, within the scope of editing Markdown files in Mark Text. |
|
+1 on this ticket. For me, these are the requests in order of priority:
I agree that the state does not need to be stored in the file, it's only something to aid viewing/editing a currently opened file. I use it for example for todo lists* and often I add sub-bullet points with extra info. These sub-lists can get large, cluttering the overview, so I've I'm not actively working on some todo, I'd like to be able to fold its sublist away...
|
|
I have a use case. When doing a quick note, I'm not sure the complete structure, so instead of using heading, I simply use indented lists, like this.
Since TOC doesn't contain indented list details, folding is very useful for reviewing and refactoring. |
|
I also wanted to support this idea because, for example, in Notion, I found this feature useful. And I use it a lot. |
|
I think that the option to collapse sections of text isn't just a navigational convenience, but also for cross-referencing purposes. For example, if there is a paragraph of text located high up near the beginning of the document that I wanted to refer to when writing a summary, the table of contents currently available allows me to find that section, jump to it, copy the paragraph and paste it temporarily at the bottom for easy reference while I'm editing and typing. The problem comes when I want to refer to several areas of text in the document, above and below the section I'm editing. In this case, it would be far more convenient if I can just collapse the unnecessary sections except for the parts that I need to refer to. Another example would be if I wanted to refer to the question prompt/guide or the marking scheme located above my answer without getting distracted by the other paragraphs in my answer. In summary, this would be a feature that not only makes navigation easier, but also allows referencing multiple sections of the document at the same time without getting distracted by the rest of the text. Hope that this is a suitable use case for this feature 😊. Just making headings collapsible would kind of make this restrictive, so I suggest maybe symbols like > or < or ^ to mark the beginning and end of a collapsible section, as well as differentiating the 'title' (the part that is shown) and 'body' (the part that is hidden). This would allow the user to collapse text in any part of the document. I understand if this isn't possible though, because I don't have that much experience in coding and markdown. Adding a "collapse all" and "expand all" option may also make it more convenient for users to reset temporary changes made to the document, for example, I can simply click "expand all" when I'm done writing my summary to read my overall answer. |
|
+1 - This is the only feature missing for me to switch to Marktext (best md editor btw) |
|
+1 |
|
+1 This feature is implemented well in other Markdown editors like Zettlr. |
|
+1 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 |
|
+1 This would be so useful! |
|
+1 |
1 similar comment
|
+1 |
and others
Describe your feature request
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.
The text was updated successfully, but these errors were encountered: