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: Tue, 6 Nov 2018 19:24:07 +0000 [thread overview]
Message-ID: <CAJ1MqVEXLdndeKfJkpy4Bw6iO0gJ518PxipwhnXO9djqyOj8HA@mail.gmail.com> (raw)
In-Reply-To: <87in1btcyo.fsf@nicolasgoaziou.fr>
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
next prev parent reply other threads:[~2018-11-06 19:33 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
2018-11-05 21:46 ` Nicolas Goaziou
2018-11-06 19:24 ` Philip Hudson [this message]
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=CAJ1MqVEXLdndeKfJkpy4Bw6iO0gJ518PxipwhnXO9djqyOj8HA@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).