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.