emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Max Nikulin <manikulin@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: text after sub headings?
Date: Fri, 24 Dec 2021 23:51:42 +0700	[thread overview]
Message-ID: <sq4tr5$otj$1@ciao.gmane.io> (raw)
In-Reply-To: <87wnjvvzgv.fsf@posteo.net>

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.



  reply	other threads:[~2021-12-24 16:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-23 16:11 text after sub headings? Robert Nikander
2021-12-23 16:54 ` Max Nikulin
2021-12-23 20:27 ` Juan Manuel Macías
2021-12-24 16:51   ` Max Nikulin [this message]
2021-12-24 20:17     ` Juan Manuel Macías
2021-12-25 13:15       ` Max Nikulin
2021-12-26  5:23         ` Ihor Radchenko
2021-12-26  9:17         ` Juan Manuel Macías
2021-12-23 23:12 ` Tim Cross
  -- strict thread matches above, loose matches on Subject: below --
2021-12-23 21:21 Robert Nikander
2021-12-23 21:47 ` John Kitchin
2021-12-23 22:10 ` Juan Manuel Macías

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='sq4tr5$otj$1@ciao.gmane.io' \
    --to=manikulin@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).