From: Nicolas Goaziou <email@example.com>
To: Ihor Radchenko <firstname.lastname@example.org>
Cc: Tom Gillespie <email@example.com>,
Subject: Re: Some commentary on the Org Syntax document
Date: Sun, 05 Dec 2021 10:28:09 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
In-Reply-To: <87y24zbm2x.fsf@localhost> (Ihor Radchenko's message of "Sun, 05 Dec 2021 14:30:14 +0800")
Ihor Radchenko <email@example.com> writes:
> Nicolas Goaziou <firstname.lastname@example.org> writes:
>> But then, you do not remove the ambiguity that is condemned in this
>> thread. The greater element/element and greater element/lesser element
>> distinctions are equivalent, albeit not identical.
> AFAIU, elements = greater-elements ∪ lesser-elements
> The current syntax draft contains section "Greater elements" defining
> all the greater-elements and section "Elements" defining lesser-elements
> However, the word "elements" also refers to all possible elements in
> some parts of the draft.
> I propose to remove the ambiguity by referring to members of
> org-element-greater-elements as "greater elements"; to
> org-element-all-elements - org-element-greater-elements as "lesser
> elements"; and to org-element-all-elements as just "elements".
I understand the proposal. I'm just pointing out that currently, the
distinction exists already in some other form—as noted, what you call
lesser elements is currently the set difference between greater elements
and elements. Therefore, it is hardly a huge step forward.
In any case, both proposals are incomplete.
>> IIUC, you want three terms for elements (I am not even talking about
>> secondary strings, which can hold objects that are not part of
For clarity, I mean three terms /in addition to "elements"/. For
example, a drawer, a paragraph and a planning line all are elements.
Yet, they may be different enough so as to deserve their own label.
>> ... and probably two for objects: terminal and non-terminal.
> Sorry, I do not understand what you refer to here.
Some objects can contain other objects. Others cannot. Per above, it may
be ambiguous to use the term "object" for both categories.
In a nutshell, naming is hard.
prev parent reply other threads:[~2021-12-05 9:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-02 9:23 Some commentary on the Org Syntax document Timothy
2021-12-02 19:00 ` Tom Gillespie
2021-12-02 19:16 ` Timothy
2021-12-04 5:26 ` Tom Gillespie
2021-12-04 6:17 ` Ihor Radchenko
2021-12-04 6:48 ` Timothy
2021-12-04 7:40 ` Ihor Radchenko
2021-12-04 8:09 ` Timothy
2021-12-04 9:41 ` Nicolas Goaziou
2021-12-04 14:00 ` Ihor Radchenko
2021-12-04 14:43 ` Nicolas Goaziou
2021-12-05 6:30 ` Ihor Radchenko
2021-12-05 9:28 ` Nicolas Goaziou [this message]
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).