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/)]

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/)]

[Philip Hudson]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

    https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.
------------------------------------------------------------------------

Regression in org-capture template handling.

I expected my (previously working) org-capture template to be
inserted into a newly-created empty Org file. The file name and
location are the output of a function specified in the template
(sequentially numbered filename).

Function `org-capture-insert-template-here' in file org-capture.el
now errors if the template specifies that its type is 'entry and it
begins with one or more lines of the general form "#+KEY value".
The error traces to a call to `org-kill-is-subtree-p', defined in file
org.el.

Fix (sorry it's not a proper patch):

Change line 1399 of org-capture.el from:

   (org-capture-verify-tree (org-capture-get :template))

to:

   (org-capture-verify-tree (replace-regexp-in-string "#\+[^\n]*\n" ""
template))

(This includes a refactoring-out of that redundant call to `org-capture-get').

NOTE: I have signed the FSF papers. In fact I've made small
contributions to Org-mode previously.

Emacs  : GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
of 2017-09-12 on hullmann, modified by Debian
Package: Org mode version 9.1.14 (9.1.14-1-g4931fc-elpa @
/home/phil/.emacs.d/elpa/org-9.1.14/)

-- 
Phil Hudson                  http://hudson-it.ddns.net
Pretty Good Privacy (PGP) ID: 0x4E482F85

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/)]

[Philip Hudson]

Two further thoughts:

1. That regexp works but it should really start with "^":

  (org-capture-verify-tree (replace-regexp-in-string "^#\+[^\n]*\n" ""
template))

2. The fix I propose is a kludge. The real problem is the semantics of
function `org-capture-insert-template-here'. My assertion: there is no
reason to believe that a completed template of type 'entry must be a
subtree in the sense of the contract of function
`org-kill-is-subtree-p'. In other words, function
`org-kill-is-subtree-p' is meant for something else. We either need a
similar-but-different special-purpose entry-template verification
function, defined in 'org-capture.el' itself, or, if we can do so
without introducing other regressions, we need to modify function
`org-kill-is-subtree-p' to accept "#+KEYWORD" in-buffer settings.
On Mon, 29 Oct 2018 at 22:47, Philip Hudson <phil.hudson@iname.com> wrote:
>
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen.  You don't know how to make a good report?  See
>
>     https://orgmode.org/manual/Feedback.html#Feedback
>
> Your bug report will be posted to the Org mailing list.
> ------------------------------------------------------------------------
>
> Regression in org-capture template handling.
>
> I expected my (previously working) org-capture template to be
> inserted into a newly-created empty Org file. The file name and
> location are the output of a function specified in the template
> (sequentially numbered filename).
>
> Function `org-capture-insert-template-here' in file org-capture.el
> now errors if the template specifies that its type is 'entry and it
> begins with one or more lines of the general form "#+KEY value".
> The error traces to a call to `org-kill-is-subtree-p', defined in file
> org.el.
>
> Fix (sorry it's not a proper patch):
>
> Change line 1399 of org-capture.el from:
>
>    (org-capture-verify-tree (org-capture-get :template))
>
> to:
>
>    (org-capture-verify-tree (replace-regexp-in-string "#\+[^\n]*\n" ""
> template))
>
> (This includes a refactoring-out of that redundant call to `org-capture-get').
>
> NOTE: I have signed the FSF papers. In fact I've made small
> contributions to Org-mode previously.
>
> Emacs  : GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.5)
> of 2017-09-12 on hullmann, modified by Debian
> Package: Org mode version 9.1.14 (9.1.14-1-g4931fc-elpa @
> /home/phil/.emacs.d/elpa/org-9.1.14/)
>
> --
> Phil Hudson                  http://hudson-it.ddns.net
> Pretty Good Privacy (PGP) ID: 0x4E482F85



-- 
Phil Hudson                  http://hudson-it.ddns.net
Pretty Good Privacy (PGP) ID: 0x4E482F85

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]

Hello,

Philip Hudson <phil.hudson@iname.com> writes:

> I expected my (previously working) org-capture template to be
> inserted into a newly-created empty Org file. The file name and
> location are the output of a function specified in the template
> (sequentially numbered filename).

Could you show your template? Could you explain how you initiate the
capture process (e.g., with arguments)? Also, could you show the desired
output?

Thank you.

Regards,

-- 
Nicolas Goaziou

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/)]

[Philip Hudson]

On Thu, 1 Nov 2018 at 22:12, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Philip Hudson <phil.hudson@iname.com> writes:
>
> Could you show your template? Could you explain how you initiate the
> capture process (e.g., with arguments)? Also, could you show the desired
> output?

Here's a minimal failing capture-completed template:

------- Cut here ------
#+FOO: bar

* Baz
------ Cut here ------

Pass this into `org-capture-verify-tree'. This will reproduce the error.

My fix strips out the leading in-buffer settings for the duration of
that call only. Effectively what gets passed into
`org-capture-verify-tree' is then this:

------- Cut here ------
* Baz
------- Cut here ------

-- 
Phil Hudson                  http://hudson-it.ddns.net
Pretty Good Privacy (PGP) ID: 0x4E482F85

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]

Philip Hudson <phil.hudson@iname.com> writes:

> Here's a minimal failing capture-completed template:
>
> ------- Cut here ------
>
> #+FOO: bar
>
> * Baz
> ------ Cut here ------

I would like to see you capture template in its elisp form, i.e., as set
in `org-capture-templates'.

Thank you.

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/)]

[Philip Hudson]

On Fri, 2 Nov 2018 at 01:35, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Philip Hudson <phil.hudson@iname.com> writes:
>
> > Here's a minimal failing capture-completed template:
> >
> > ------- Cut here ------
> >
> > #+FOO: bar
> >
> > * Baz
> > ------ Cut here ------
>
> I would like to see you capture template in its elisp form, i.e., as set
> in `org-capture-templates'.
>
> Thank you.

Why? This is a regression.

-- 
Phil Hudson                  http://hudson-it.ddns.net
Pretty Good Privacy (PGP) ID: 0x4E482F85

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]

Hello,

Philip Hudson <phil.hudson@iname.com> writes:

> Why? This is a regression.

You have something in your configuration that no longer works. Generally
speaking, that could be a plain regression, indeed. But you may also
have been relying on unspecified behavior: this might be a documentation
bug.

I cannot see your template, since you did not send it yet. I assume it
uses an `entry' type. Barring `plain', all capture types enforce
a certain structure for contents. The `entry' type expects a node, which
is roughly a headline plus contents, as noted in the manual:

     ‘entry’
          An Org mode node, with a headline.  Will be filed as the child
          of the target entry or as a top-level entry.  The target file
          should be an Org file.

You seem to capture something that doesn't correspond to this
definition, hence the error. Note that keywords are global, so you could
equivalently write:

    * Baz
    #+FOO: bar

Now, with your template, I could reproduce the problem and try to know
when and how the change happened, and guess the intent of `entry' type
before this change.

Maybe the documentation could be clearer, too. Suggestions welcome.

Regards,

-- 
Nicolas Goaziou

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/)]

[Philip Hudson]

On Sat, 3 Nov 2018 at 08:34, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Philip Hudson <phil.hudson@iname.com> writes:
>
> > Why? This is a regression.
>
> You have something in your configuration that no longer works.

Agreed.

> Generally
> speaking, that could be a plain regression, indeed. But you may also
> have been relying on unspecified behavior: this might be a documentation
> bug.

Also agreed.

> I cannot see your template, since you did not send it yet. I assume it
> uses an `entry' type.

No assumption involved. I stated so plainly.

> Barring `plain', all capture types enforce
> a certain structure for contents. The `entry' type expects a node, which
> is roughly a headline plus contents, as noted in the manual:
>
>      ‘entry’
>           An Org mode node, with a headline.  Will be filed as the child
>           of the target entry or as a top-level entry.  The target file
>           should be an Org file.

Agreed, understood, and 100% the case in both my case (I'm afraid
you'll just have to take my word for it) and in the trivial but
effectively illustrative minimal failing case I gave you. Have you
tested that case and confirmed that my report is correct?

> You seem to capture something that doesn't correspond to this
> definition, hence the error.

That is a completely erroneous leap of logic. Try the minimal failing case.

> Note that keywords are global, so you could
> equivalently write:
>
>     * Baz
>     #+FOO: bar

Agreed, understood.

> Maybe the documentation could be clearer, too. Suggestions welcome.

The doco seems fine to me. I relied on it for the definition of my
template, which has worked as expected for years.


-- 
Phil Hudson                  http://hudson-it.ddns.net
Pretty Good Privacy (PGP) ID: 0x4E482F85

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]

Hello,

Philip Hudson <phil.hudson@iname.com> writes:

> On Sat, 3 Nov 2018 at 08:34, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

>> I cannot see your template, since you did not send it yet. I assume it
>> uses an `entry' type.
>
> No assumption involved. I stated so plainly.

Indeed.

>> Barring `plain', all capture types enforce
>> a certain structure for contents. The `entry' type expects a node, which
>> is roughly a headline plus contents, as noted in the manual:
>>
>>      ‘entry’
>>           An Org mode node, with a headline.  Will be filed as the child
>>           of the target entry or as a top-level entry.  The target file
>>           should be an Org file.
>
> Agreed, understood, and 100% the case in both my case (I'm afraid
> you'll just have to take my word for it) and in the trivial but
> effectively illustrative minimal failing case I gave you.

No, it is not the case. AFAIU, in the minimal failing case, you capture

    #+FOO: bar
    * Baz

This is _not_ a node. A node starts with a headline and everything is
contained within that headline. So it doesn't qualify as a valid `entry'
capture type.

> The doco seems fine to me. I relied on it for the definition of my
> template, which has worked as expected for years.

It might be that you misinterpreted the definition of a node. Hence my
suggestion to improve the documentation.

In any case, you can simply move the keywords below the headline, and be
done with it.

Regards,

-- 
Nicolas Goaziou

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/)]

[Philip Hudson]

On Sun, 4 Nov 2018 at 14:03, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Philip Hudson <phil.hudson@iname.com> writes:
>
> > On Sat, 3 Nov 2018 at 08:34, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> >> I cannot see your template, since you did not send it yet. I assume it
> >> uses an `entry' type.
> >
> > No assumption involved. I stated so plainly.
>
> Indeed.
>
> >> Barring `plain', all capture types enforce
> >> a certain structure for contents. The `entry' type expects a node, which
> >> is roughly a headline plus contents, as noted in the manual:
> >>
> >>      ‘entry’
> >>           An Org mode node, with a headline.  Will be filed as the child
> >>           of the target entry or as a top-level entry.  The target file
> >>           should be an Org file.
> >
> > Agreed, understood, and 100% the case in both my case (I'm afraid
> > you'll just have to take my word for it) and in the trivial but
> > effectively illustrative minimal failing case I gave you.
>
> No, it is not the case. AFAIU, in the minimal failing case, you capture
>
>     #+FOO: bar
>     * Baz
>
> This is _not_ a node. A node starts with a headline and everything is
> contained within that headline. So it doesn't qualify as a valid `entry'
> capture type.

That's disappointing, and, obviously, news to me. So I have not
encountered a regression but rather a tightening of the existing
documented contract. Is that a fair interpretation of what you're
saying? If so, and not that I doubt you, do you have a reference for
that?

> > The doco seems fine to me. I relied on it for the definition of my
> > template, which has worked as expected for years.
>
> It might be that you misinterpreted the definition of a node. Hence my
> suggestion to improve the documentation.

If this is the only place that the definition should appear (not
saying that I know or believe it is), then are we not free to say that
it could be otherwise? Effectively, in terms of actual behavior, the
definition of "node" (at least in this context) has been otherwise,
for several years at least. In other words, absent a formal definition
of interface/contract, the implementation /is/ the interface; this is
an implementation change, and thus (arguably) a regression
nevertheless.

In still other words, I'm arguing this:

The idea of 'entry type for templates, and of a node as we are
discussing it, is that a well-formed and valid Org file is composed
exclusively of these entities and nothing else. Correct?

If that is true, then, under your definition, no well-formed and valid
Org file constructed only from Org-capture using templates of the
'entry type can ever start with any number of #+FOO in-buffer
settings. This is clearly at odds with the established definition of a
well-formed and valid Org file.

> In any case, you can simply move the keywords below the headline, and be
> done with it.

Sorry if this is getting tiresome. At this point I'm content for you
to close this issue and move on if you'd rather. I'll change my
template type to 'plain, or find some other workaround. But if you'd
like to keep going for the sake of clarifying what the right and
proper meaning of 'entry and "node" are then I'm glad to participate.

-- 
Phil Hudson                  http://hudson-it.ddns.net
Pretty Good Privacy (PGP) ID: 0x4E482F85

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]

Hello,

Philip Hudson <phil.hudson@iname.com> writes:

> On Sun, 4 Nov 2018 at 14:03, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:

>> No, it is not the case. AFAIU, in the minimal failing case, you capture
>>
>>     #+FOO: bar
>>     * Baz
>>
>> This is _not_ a node. A node starts with a headline and everything is
>> contained within that headline. So it doesn't qualify as a valid `entry'
>> capture type.
>
> That's disappointing, and, obviously, news to me. So I have not
> encountered a regression but rather a tightening of the existing
> documented contract. Is that a fair interpretation of what you're
> saying? If so, and not that I doubt you, do you have a reference for
> that?

It is not a tightening of anything. The function responsible for the
raised error is `org-capture-verify-tree'. It is called from the
function responsible for capturing `entry' types since December 2010:

    commit 8aacc708dd038fd0d351abbed04d49f813f8a7bf
    Author: Carsten Dominik <carsten.dominik@gmail.com>
    Date:   Thu Dec 16 16:51:04 2010 +0100

        Capture: Better error message for invalid entry-type templates

It seems to me the intent is clear, and from the documentation,
I wouldn't have thought about inserting data before the headline. I'm
surprised that your template even worked at some point.

I did my homework, though. I tried the following set-up

    (setq org-capture-templates
          '(("B" "BUG" entry (file "/tmp/bug-capture.org") "#+BAR: baz\n* Foo"
             :immediate-finish t)))

Even in Org 8.2.10, which is old in my book, I got an error mentioning
the template was invalid.

> The idea of 'entry type for templates, and of a node as we are
> discussing it, is that a well-formed and valid Org file is composed
> exclusively of these entities and nothing else. Correct?

Not at all. I'm absolutely not talking about what is a valid Org file.
See <https://orgmode.org/worg/dev/org-syntax.html> for this.

I'm talking about what can be captured using an `entry' template, i.e.,
a node/heading/entry and that's it.

> Sorry if this is getting tiresome. At this point I'm content for you
> to close this issue and move on if you'd rather. I'll change my
> template type to 'plain, or find some other workaround. But if you'd
> like to keep going for the sake of clarifying what the right and
> proper meaning of 'entry and "node" are then I'm glad to participate.

Entry, node, and heading (and to some extent, headline) are synonyms.
They mean star(s) at the beginning of line, followed by a space, and
optionally other stuff of that line.

Contents can be anything as long as no line starts with as many or less
stars followed by a space, i.e., there is no headline of a lesser or
equal level.

In any case, if documentation needs to be clarified, please let me know.

Regards,

-- 
Nicolas Goaziou

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/)]

[Philip Hudson]

On Mon, 5 Nov 2018 at 21:46, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> Philip Hudson <phil.hudson@iname.com> writes:
>
> > On Sun, 4 Nov 2018 at 14:03, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> >> No, it is not the case. AFAIU, in the minimal failing case, you capture
> >>
> >>     #+FOO: bar
> >>     * Baz
> >>
> >> This is _not_ a node. A node starts with a headline and everything is
> >> contained within that headline. So it doesn't qualify as a valid `entry'
> >> capture type.
> >
> > That's disappointing, and, obviously, news to me. So I have not
> > encountered a regression but rather a tightening of the existing
> > documented contract. Is that a fair interpretation of what you're
> > saying? If so, and not that I doubt you, do you have a reference for
> > that?
>
> It is not a tightening of anything. The function responsible for the
> raised error is `org-capture-verify-tree'. It is called from the
> function responsible for capturing `entry' types since December 2010:
>
>     commit 8aacc708dd038fd0d351abbed04d49f813f8a7bf
>     Author: Carsten Dominik <carsten.dominik@gmail.com>
>     Date:   Thu Dec 16 16:51:04 2010 +0100
>
>         Capture: Better error message for invalid entry-type templates
>
> It seems to me the intent is clear, and from the documentation,
> I wouldn't have thought about inserting data before the headline.

Ah-ha! I thought not. I want to contest the use of the word "data"
here; see below.

> I'm
> surprised that your template even worked at some point.

This is baffling to me, but ultimately unimportant..

> I did my homework, though. I tried the following set-up
>
>     (setq org-capture-templates
>           '(("B" "BUG" entry (file "/tmp/bug-capture.org") "#+BAR: baz\n* Foo"
>              :immediate-finish t)))
>
> Even in Org 8.2.10, which is old in my book, I got an error mentioning
> the template was invalid.
>
> > The idea of 'entry type for templates, and of a node as we are
> > discussing it, is that a well-formed and valid Org file is composed
> > exclusively of these entities and nothing else. Correct?
>
> Not at all. I'm absolutely not talking about what is a valid Org file.
> See <https://orgmode.org/worg/dev/org-syntax.html> for this.
>
> I'm talking about what can be captured using an `entry' template, i.e.,
> a node/heading/entry and that's it.
>
> > Sorry if this is getting tiresome. At this point I'm content for you
> > to close this issue and move on if you'd rather. I'll change my
> > template type to 'plain, or find some other workaround. But if you'd
> > like to keep going for the sake of clarifying what the right and
> > proper meaning of 'entry and "node" are then I'm glad to participate.
>
> Entry, node, and heading (and to some extent, headline) are synonyms.
> They mean star(s) at the beginning of line, followed by a space, and
> optionally other stuff of that line.
>
> Contents can be anything as long as no line starts with as many or less
> stars followed by a space, i.e., there is no headline of a lesser or
> equal level.
>
> In any case, if documentation needs to be clarified, please let me know.

I'm not ready to let go of the question of the definition of an entry.

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). 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.

Can we agree that what we are doing here is lexing? That is essential
to my argument that follows. If we are, then I think I have a good
case to make. Here it is:

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.

I hope I'm making myself clear. Am I wrong about any of this, and if
so, why and how? What I really want to know is: what is wrong with my
suggested change, temporarily stripping leading in-buffer settings
during the call to `org-capture-verify-tree'? What breaks? What do we
lose by implementing it? What do we gain by not implementing it? What
depends on such a change /not/ being made? As I said myself, it feels
like an inglorious kludge, but would it actually be wrong in some way
within the semantics and working constraints of Org? Should that
temporary stripping-out of preceding in-buffer settings actually be
implemented not in `org-capture-verify' but in the core-Org function
it calls, `org-kill-is-subtree-p', thus making the recognition and
acceptance of preceding in-buffer settings Org-wide?

I know my knowledge and understanding of Org are nowhere near as deep
as yours, Nic. I realize as I write this that it may all come down to
something I've just failed to grasp correctly, but for the life of me,
at the moment, I can't see what it might be. I also have that sinking
feeling that when it does all become clear I'm going to feel pretty
stupid and regret having taken up so much bandwidth. So I offer this
with some trepidation, but also with some hope that I may have spotted
something that has thus far gone unnoticed and unremarked, in the
spirit of wanting to make this magnificent piece of software even
better than it already is.


-- 
Phil Hudson                  http://hudson-it.ddns.net
Pretty Good Privacy (PGP) ID: 0x4E482F85

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]

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

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/)]

[Philip Hudson]

On Sat, 10 Nov 2018 at 10:39, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>
> I stand on my ground: capturing an entry should be limited to real
> entries, no exception.

Fine. Thanks for your patience, and sorry I demanded so much of it.

-- 
Phil Hudson                  http://hudson-it.ddns.net
Pretty Good Privacy (PGP) ID: 0x4E482F85