text after sub headings?

text after sub headings?

[Robert Nikander]

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.

Re: text after sub headings?

[Max Nikulin]

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

Re: text after sub headings?

[Juan Manuel Macías]

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 

Re: text after sub headings?

[Robert Nikander]

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. 

Re: text after sub headings?

[John Kitchin]

[-- 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 --]

Re: text after sub headings?

[Juan Manuel Macías]

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”

Re: text after sub headings?

[Tim Cross]

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. 

Re: text after sub headings?

[Max Nikulin]

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.

Re: text after sub headings?

[Juan Manuel Macías]

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.

Re: text after sub headings?

[Max Nikulin]

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.

Re: text after sub headings?

[Ihor Radchenko]

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

Re: text after sub headings?

[Juan Manuel Macías]

[-- 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 --]