emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Philip Hudson <phil.hudson@iname.com>
To: emacs orgmode-mailinglist <emacs-orgmode@gnu.org>
Subject: 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/)]
Date: Sun, 4 Nov 2018 16:31:22 +0000	[thread overview]
Message-ID: <CAJ1MqVF+vB-+p=JeU9wrUGu3ta_UKHZ-88dcOf_bsaeL6wDTFw@mail.gmail.com> (raw)
In-Reply-To: <8736sh9by2.fsf@nicolasgoaziou.fr>

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

  reply	other threads:[~2018-11-04 16:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-29 22:47 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
2018-11-01 10:04 ` Philip Hudson
2018-11-01 21:34 ` Nicolas Goaziou
2018-11-02  0:24   ` Philip Hudson
2018-11-02  1:35     ` Nicolas Goaziou
2018-11-02  9:22       ` Philip Hudson
2018-11-03  8:34         ` Nicolas Goaziou
2018-11-03  9:09           ` Philip Hudson
2018-11-04 14:03             ` Nicolas Goaziou
2018-11-04 16:31               ` Philip Hudson [this message]
2018-11-05 21:46                 ` Nicolas Goaziou
2018-11-06 19:24                   ` Philip Hudson
2018-11-10 10:39                     ` Nicolas Goaziou
2018-11-10 15:06                       ` Philip Hudson

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='CAJ1MqVF+vB-+p=JeU9wrUGu3ta_UKHZ-88dcOf_bsaeL6wDTFw@mail.gmail.com' \
    --to=phil.hudson@iname.com \
    --cc=emacs-orgmode@gnu.org \
    /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).