Re: text after sub headings?

[Max Nikulin <manikulin@gmail.com>]

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.