From: Ihor Radchenko <yantar92@posteo.net>
To: Tom Alexander <tom@fizz.buzz>
Cc: emacs-orgmode@gnu.org
Subject: Re: Clarification on blank lines following list items
Date: Sat, 19 Aug 2023 08:43:38 +0000 [thread overview]
Message-ID: <87bkf3o211.fsf@localhost> (raw)
In-Reply-To: <9372527e-3852-419e-936a-7b4dd38cc847@app.fastmail.com>
"Tom Alexander" <tom@fizz.buzz> writes:
> I am noticing the list items have some very context-sensitive specific behavior regarding ownership of the trailing blank lines. I was hoping to get some clarification on this (namely, are my observations correct, am I stumbling across a bug, or have I not dug deep enough to suss out the real rules?). The org-mode documentation states:
>
>> With the exception of list items and footnote definitions blank lines belong to the preceding element with the narrowest possible scope
>
> but it does not state who ends up owning those blank lines.
I can see how this explanation steered you into wrong line of thoughts.
It should better be explained from the widest scope to the narrowest
scope, not the opposite.
Greater Org elements are generally represented by contents where child
elements are located + markup defining the greater element itself +
optional trailing blank lines.
For example, drawers are
:NAME:
<contents begin>
...
<contents end>:END:
<blank lines>
Naturally, blank lines are the attribute of such drawer - they belong to
it and are recorded as :post-blank property.
The above works for many greater elements. However, it becomes a bit
tricky when a greater element does not have any "end" delimiter:
--------
- item
Some text
Or even
:drawer:
with text
:end:
Not an item.
--------
Now, assigning contents vs. blank lines is not so obvious. We can either
include these blank lines into contents or keep them separate within
:post-blank property.
Then, there are two kinds of greater elements that can end with blank
lines without separator:
1. Elements where blank lines do not affect parsing (headlines)
2. Elements where trailing blank lines are syntactically meaningful and
by themselves serve as a marker of element ending.
- footnote-definition ends when Org see two consecutive blank lines
or a heading or another footnote-definition.
- plain-list also uses two consecutive blank lines as delimiter.
In the second case, Org makes the plain-list/footnote-definition element
"own" the blank lines (set :post-blank) instead of putting these blank
lines inside contents. If we did otherwise, changes in contents could
make the parent plain-list/footnote-definition invalid - if the double
blank delimiter is edited away.
-----
Further, there is a special case with greater elements without contents:
* Heading with no contents
* Another heading
The first heading does not have contents, yet we want to record the fact
that it has multiple blank lines before the next element - :post-blank
here is set, unlike heading with contents.
-----
Finally, :post-blank in items is special.
Consider:
- item 1
- item 2
- item 3
We do not treat blank between items as parts of their paragraphs
historically. Also, it makes sense for such short items.
(there are actually some reasons why we might want to alter this
historical convention, but for now it is how it is)
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
next prev parent reply other threads:[~2023-08-19 8:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-19 5:30 Clarification on blank lines following list items Tom Alexander
2023-08-19 8:43 ` Ihor Radchenko [this message]
2023-08-21 1:56 ` Tom Alexander
2023-08-22 7:47 ` Ihor Radchenko
2023-08-22 8:26 ` Ihor Radchenko
2023-08-24 18:46 ` Tom Alexander
2023-09-16 11:26 ` Ihor Radchenko
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=87bkf3o211.fsf@localhost \
--to=yantar92@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=tom@fizz.buzz \
/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).