I see why this is not possible, given the text format of an org file. But I am curious if people think it would be useful. This is a bit off-topic maybe, but I’m imagining what I would do if I created something like org-mode using another underlying format. Example: * Top Some text under “Top” ** A level-2 heading Text under level-2 heading ** Another level-2 heading Text under the second level-2 heading More text under “Top” So if the level-2 headings were collapsed we would still see this. ** Could have more sub-headings here More top level text, etc.
On 23/12/2021 23:11, Robert Nikander wrote: > I see why this is not possible, given the text format of an org file. > But I am curious if people think it would be useful. This is a bit > off-topic maybe, but I’m imagining what I would do if I created > something like org-mode using another underlying format. Have you seen the following and links therein? https://orgmode.org/worg/org-faq.html#closing-outline-sections 8.1. Can I close an outline section without starting a new section? Org-mode Frequently Asked Questions
Hi Robert,
Robert Nikander writes:
> I see why this is not possible, given the text format of an org file.
> But I am curious if people think it would be useful. This is a bit
> off-topic maybe, but I’m imagining what I would do if I created
> something like org-mode using another underlying format.
>
> Example:
>
> * Top
> Some text under “Top”
> ** A level-2 heading
> Text under level-2 heading
> ** Another level-2 heading
> Text under the second level-2 heading
> More text under “Top”
> So if the level-2 headings were collapsed we would still see this.
> ** Could have more sub-headings here
> More top level text, etc.
It is an interesting question; however, I would say that this is not a
useful or realistic structure. Regardless of the Org trees/subtrees and
their folding ability (indicating that each thing is at a certain
level), I think that a content will be more useful and intelligible if
it is easy and obvious to extract a table of contents (with headings and
levels) from that content. Let's imagine not we are in Org but writing a
novel on a typewriter. It could be a two-voice novel, with a main
narrator and a "secondary" narrator. The first structure could be:
Part I (Narrator A)
Some text under Part I (Narrator A)
Chaper 1
Text under Chapter 1 (Narrator B)
Chapter 2
Text under Chapter 2 (Narrator B)
?? More text under Part I (Narrator A)
More chapters (Narrator B)
?? More Part I text, etc. (Narrator A)
(...)
Although we feel that our structure is very clear, our publisher will
probably force us to include some kind of division into the texts marked
with "??". I mean, it's not that easy to escape from the (graphical)
levels, parts and chapters, even if it is by editorial imposition or for
not confuse our readers. We can, for example, call Part II "Interlude",
or add the first text marked with "??" after a graphic separation (some
dashes, for example: ------). Although the literary structure is
complex, its graphical representation always has limits:
Part I (Narrator A)
Some text under Part I (Narrator A)
Chaper 1
Text under Chapter 1 (Narrator B <= Narrator A)
Chapter 2
Text under Chapter 2 (Narrator B <= Narrator A)
Division 1 (forced by the publishing house = Part II?)
More text under Part II (Narrator A)
More chapters (Narrator B)
(...)
Best regards,
Juan Manuel
Max Nikulin wrote: > Have you seen the following and links therein? > https://orgmode.org/worg/org-faq.html#closing-outline-sections No, I hadn't found that. Thanks. Those links answer my question. Juan Manuel Macías wrote: > It is an interesting question; however, I would say that this is not a > useful or realistic structure. Regardless of the Org trees/subtrees and > their folding ability (indicating that each thing is at a certain > level), I think that a content will be more useful and intelligible if > […] I see your point. Maybe it depends on how you use org-mode and how you imagine the meaning of the "*" items. I see some disagreement about this in the old threads that Max linked to. No need to rehash it deeply here again; I was just curious. The way I'm using org-mode so far, I'm not exporting to other formats, and I can see a use for collapsible sections in the middle of a larger chunk of text. I can already kind of do it with a "-" list item, like this. (Or other things like code blocks, etc) * Heading Top Text Top Text - Sub This can be hidden if I hit 'tab' key on "Sub". More Top Text More Top Text If you view a "*" item as "book section", it's confusing. But if you view a "*" item as "collapsible thing", then it makes more sense.
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --] You can also use drawers (as an alternative to inline tasks) for collapsible content. Another potential is to use blocks. You can define your own kind of blocks, or even just use an org block and it is collapsible. John ----------------------------------- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Thu, Dec 23, 2021 at 4:22 PM Robert Nikander <robert.nikander@icloud.com> wrote: > Max Nikulin wrote: > > Have you seen the following and links therein? > > https://orgmode.org/worg/org-faq.html#closing-outline-sections > > No, I hadn't found that. Thanks. Those links answer my question. > > Juan Manuel Macías wrote: > > It is an interesting question; however, I would say that this is not a > > useful or realistic structure. Regardless of the Org trees/subtrees and > > their folding ability (indicating that each thing is at a certain > > level), I think that a content will be more useful and intelligible if > > […] > > I see your point. > > Maybe it depends on how you use org-mode and how you imagine the meaning > of the "*" items. I see some disagreement about this in the old threads > that Max linked to. No need to rehash it deeply here again; I was just > curious. > > The way I'm using org-mode so far, I'm not exporting to other formats, and > I can see a use for collapsible sections in the middle of a larger chunk of > text. I can already kind of do it with a "-" list item, like this. (Or > other things like code blocks, etc) > > * Heading > Top Text > Top Text > - Sub > This can be hidden if I hit 'tab' key on "Sub". > More Top Text > More Top Text > > If you view a "*" item as "book section", it's confusing. But if you view > a "*" item as "collapsible thing", then it makes more sense. > > > > [-- Attachment #2: Type: text/html, Size: 2809 bytes --]
Robert Nikander writes:
> If you view a "*" item as "book section", it's confusing. But if you
> view a "*" item as "collapsible thing", then it makes more sense.
I understand your use case. But I think in that context Org headings
would still be useful (at least they remind us at what level we're). For
example, some headings could be used for those parts with a tag
:not_a_heading:. I sometimes use something like that, and then I remove
those tagged headings on export or convert them to another type of
separator, it depends on the case:
* Top
Some text under “Top”
** A level-2 heading
Text under level-2 heading
** Another level-2 heading
Text under the second level-2 heading
* Some descriptive title :not_a_heading:
More text under “Top”
Robert Nikander <robert.nikander@icloud.com> writes:
> I see why this is not possible, given the text format of an org file. But I am curious if people think it would be useful. This is a bit off-topic maybe, but I’m imagining what I would do if I created something like org-mode using another underlying format.
>
> Example:
>
> * Top
> Some text under “Top”
> ** A level-2 heading
> Text under level-2 heading
> ** Another level-2 heading
> Text under the second level-2 heading
> More text under “Top”
> So if the level-2 headings were collapsed we would still see this.
> ** Could have more sub-headings here
> More top level text, etc.
While I can see how the structure you suggest could be useful in some
use cases, the big drawback is that to implement this, you would have to
add some new 'marker' to indicate where the contents of a
section/sub-section end. Personally, I would find the need to add
section end markers more inconvenient than having this feature, which is
something I would probably only use very rarely. I also suspect it would
have a processing penalty as org would now need to search for and track
matching end markers for each section rather than just searching for
another heading marker of the same level when performing folding.
In my use cases, it is extremely rare to have a situation where I have
sub headings and want to add something at the end which is part of the
parent heading, but which must follow the sub headings. Where I have
found such a structure useful, the contents of the sub headings tend to
be small and more suitable either for a list or one of the other
#+begin_* block types.
One of the original benefits of org mode was simplicity and a basis
built on simple text files. Maintaining that simplicity requires loss of
some flexibility. The more we complicate the model, the less simple it
remains and the more bugs we get.
On 24/12/2021 03:27, Juan Manuel Macías wrote: > Robert Nikander writes: > >> I see why this is not possible, given the text format of an org file. >> But I am curious if people think it would be useful. While considered isolated, vim feature "set foldmethod=marker" with explicit open and closed markers ("{{{" and "}}}" by default) is more flexible. There are at least 2 problems with Org: performance penalty and rather reach lightweight markup, so a lot of marker variants are busy already. > Although we feel that our structure is very clear, our publisher will > probably force us to include some kind of division into the texts marked > with "??". I mean, it's not that easy to escape from the (graphical) > levels, parts and chapters, even if it is by editorial imposition or for > not confuse our readers. We can, for example, call Part II "Interlude", > or add the first text marked with "??" after a graphic separation (some > dashes, for example: ------). Although the literary structure is > complex, its graphical representation always has limits: Text books and magazines may contain insets (side notes), sometimes even page-long ones. They present independent material that may be interesting or useful in particular context or may be just skipped when a reader is concentrated on main material. Such inset may be considered as a heading that is inserted in the middle of another section. It may have larger margins, smaller font, distinct font face, another background color, box around or just rule at some side, so readers have clear notion where it ends and main material continues. Export filter may solve the problem by treating specially marked headings as continuation of text. Aside from export, it may be notes interspersed with deeper details (debug logs, etc.) It would be nice to be able to switch between 2 reading modes: all details are collapsed to quickly skim through main steps and conclusions or all details are open (in particular subtree). Plain list items, #+begin_/#+end_ blocks may be folded, drawers may be expanded but only individually. Besides list items, deeper nested substructure may be a problem, e.g. neither of them may contain headings. Using of such construct is not perfect but mostly bearable. The following is not a feature request just some thoughts how to achieve convenient reading without heading closing syntax. In addition to current heading visibility cycle, there may be commands increasing or decreasing "zoom level" for the whole document or for the current subtree. Headings may have a "lense" property that may change zoom level when such section becomes visible (absolute value or relative adjustment in respect to parent, positive or negative). So in response to "zoom in" command some headings are unfolded, some remains collapsed. Visibility effect to some extent is similar to explicit end of subheading.
Max Nikulin writes: > Text books and magazines may contain insets (side notes), sometimes > even page-long ones. They present independent material that may be > interesting or useful in particular context or may be just skipped > when a reader is concentrated on main material. Such inset may be > considered as a heading that is inserted in the middle of another > section. It may have larger margins, smaller font, distinct font face, > another background color, box around or just rule at some side, so > readers have clear notion where it ends and main material continues. This is complex layout, something that DTP programs (InDesign, Quark, Scribus) do very well as they work on the concept of multiple threads of connected text boxes. [offtopic: in LaTeX there is an attempt to emulate that with the flowfram package, with obvious limitations. And the Sile typesetting system is very interesting and promising, which tries to combine the WYSIWYM style of TeX and the linked text boxes of DTP programs: https://sile-typesetter.org/]. But --- returning to the topic---, even so, there is always an underlying notion of hierarchy, levels and dependency, which is what I was referring to: there is a skeleton. I think that Org's system of trees and nodes, agnostic of any typographic format, is enough to maintain that hierarchy. In fact, I have some works with a very complex output starting simply from Org (right now I'm with a trilingual edition, using flowfram: for example, certain Org nodes are exported as flowfram boxes). Obviously, that can also be done from XML (an example of a combination of xml and LuaTeX: https://www.speedata.de/en/). But I think, perhaps in a somewhat quixotic way, that Org has tremendous potential and can play very well in that league. XML is more accurate; but Org is a great compendium of resources.
On 25/12/2021 03:17, Juan Manuel Macías wrote: > Max Nikulin writes: > >> It may have larger margins, smaller font, distinct font face, >> another background color, box around or just rule at some side, so >> readers have clear notion where it ends and main material continues. > > This is complex layout, something that DTP programs (InDesign, Quark, > Scribus) do very well as they work on the concept of multiple threads of > connected text boxes. It is not necessary complex layout. It is a decoration similar to pictures in fiction books. Unlike figures such additions are not strictly important to understand material. In printed form it is like figures however. Insets are appropriate in particular places, but tolerate some shift due to paging. This particular examples has internal structure: http://algorithmics.lsi.upc.edu/docs/Dasgupta-Papadimitriou-Vazirani.pdf#page=135 Book reader on small phone screen might require a tap to show all additional material. On wide screen in may appear on margins and visible by default. In Org it migh remain collapsed when heading is expanded while text around is visible. I have not worked with complex documents in DTP programs. In my opinion, LaTeX deals much better with figures (plots, drawings) in scientific papers than office software. When users complains that LaTeX puts at their figures and table at the end of the document it usually means that they copy-pasted markup explicitly forbidding most of usual places for floats (e.g. page completely filled with figures). It is possible to create insets in Org Mode document, but it is not native support. In a bit broader sense insets do not violates tree structure - Branch: Section Heading - Leaf: section text - Branch: Inset section Heading - Leaf: inset section text - Branch: Inset Subsection Heading 1 - Leaf: Inset subsection 1 text - Branch: Inset Subsection Heading 2 - Leaf: Inset subsection 2 text - Leaf: section text continues Another example when it is convenient to have text itermixed with headings is notes. Tree structure is too rigid, particular note may be appropriate to several topics. Important point that sometimes it is better to have particular order within some topic, if ordering is not required than all links may appear before subheadings. So not text is put to one topic, other ones contains links. Ideally it should appear like * Topic 2 some general notes *** Note 2.1... *** Note 2.2... [[#note_from_other_topic1]] contains some interesting details *** Note 2.4... [[#note_from_other_topic2]] contains other interesting details *** Note 2.6... It would be nice to have links visually distinct from headings and there is no real reason to collapse link if description text is just a couple of line. I do not ask to change anything. I admit that nobody has bright idea how to properly implement it. I am just against statements that Org is ideal in respect to sectioning and covers all use cases. My opinion that it is limitation, there are some workarounds and trade-offs for each particular case. Anyway there is no unambiguously better tool.
Max Nikulin <manikulin@gmail.com> writes:
> * Topic 2
> some general notes
> *** Note 2.1...
> *** Note 2.2...
> [[#note_from_other_topic1]]
> contains some interesting details
This reminds me of org-transclusion.
Best,
Ihor
[-- Attachment #1: Type: text/plain, Size: 1663 bytes --] Max Nikulin writes: > It is not necessary complex layout. It is a decoration similar to > pictures in fiction books. Unlike figures such additions are not > strictly important to understand material. In printed form it is like > figures however. Insets are appropriate in particular places, but > tolerate some shift due to paging. Generally, any scenario where graphic and textual content must be distributed and managed is already complex layout. Although there are several levels of complexity, and in many cases visual control is necessary. In any case, TeX is not intended for (stricto sensu) layout but for typesetting, which is where DTP programs often fail. This does not mean that highly complex pages cannot be achieved in TeX, but the strong point of TeX is the automation of processes and repeated structures, while the strong point of DTP programs is visual layout design, more focused on magazines, newspapers, posters, etc. There are "intermediate places", and in TeX there are still unresolved issues. For example: the possibility of working with independent text flows (for example, create two parallel TeX processes: one for even pages and another for odd pages) or grid typesetting (in LaTeX it is almost impossible and in ConTeXt some advances have been made) although I am very critical of the grid composition, which has become a plague lately. Anyway, in order not to get too off the topic, here are a couple of examples that I made (one of them with flowfram), exporting an inline task to LaTeX through an ad hoc filter: https://i.imgur.com/8ERXNWp.png https://i.imgur.com/mpFRL9h.png (code attached) Best regards, Juan Manuel [-- Attachment #2: tests.org --] [-- Type: application/vnd.lotus-organizer, Size: 16218 bytes --]