Re: Bug: Capture template insertion fails with #+FOO [9.1.14 (9.1.14-1-g4931fc-elpa @ /home/phil/.emacs.d/elpa/org-9.1.14/)]

[Nicolas Goaziou <mail@nicolasgoaziou.fr>]

Hello,

Philip Hudson <phil.hudson@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