Hello,
Philip Hudson <phil.hud...@iname.com> writes:
> You have been very clear and categorical about the definition of a
> top-level entry/node/heading as a chunk of text starting with a single
> asterisk (followed by whitespace, arbitrary heading text, optional
> tags and optional further lines of text -- the foundational structure
> all Org users are familiar with).
Not a single asterisk. One or more asterisks.
> You insist that if there is
> Something Else before that asterisk -- "data", in your latest reply --
> then your chunk of text is simply and categorically not an entry. Such
> a chunk of text may or may not /contain/ an entry, but it is
> definitely not itself an entry.
Correct.
> For any preceding Something Else to disqualify a chunk of text as an
> entry, it must first be Something. Lexically speaking, in-buffer
> settings are comments; thus, lexically speaking, they are whitespace;
> thus, lexically speaking, they are Nothing, not Something. That is my
> argument for allowing preceding in-buffer settings within the
> definition of an entry, not just in the context of org-capture but
> throughout Org.
Org has no comment syntax, not in the sense of what you would expect in
a programming language. It has something called a "comment", e.g.,
# This is a comment
but this is meaningful for the exporter only. In an Org document, it is
behaves as a paragraph, e.g.:
1. Item1
# Comment
1. Item2
instead of
1. Item1
# Comment
2. Item2
There is no Nothing in an Org document.
Of course, there syntactical elements in such a document. #+FOO: is one
of them. So are #+BEGIN_CENTER and CLOCK:. But there is no reason to
support capturing them before an entry, and not regular text. This is
just inconsistent.
This is also useless, as I pointed out already, since the location of
keywords in a document doesn't matter. They need not be before the first
heading.
Eventually, it is awkward. Think about capturing an entry with text
before it, in the "Target" node below:
* Target
Target contents
** Child
Child contents
It could become:
* Target
Target contents
** Child
Child contents
Captured before
** Captured
Captured contents
i.e., you modify "Child" contents even though you capture into "Target".
It is possible that someone may come up with a use-case for that, but
I would suggest them to implement their own capture mechanism. Org
shouldn't support that.
I stand on my ground: capturing an entry should be limited to real
entries, no exception.
Regards,
--
Nicolas Goaziou
