From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philip Hudson 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 Message-ID: References: <87ftwkbhxs.fsf@nicolasgoaziou.fr> <87ftwk9s8e.fsf@nicolasgoaziou.fr> <877ehua7ab.fsf@nicolasgoaziou.fr> <8736sh9by2.fsf@nicolasgoaziou.fr> <87in1btcyo.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([208.118.235.92]:33400) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gK76h-0002wo-7P for emacs-orgmode@gnu.org; Tue, 06 Nov 2018 14:33:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gK6y1-0007xQ-32 for emacs-orgmode@gnu.org; Tue, 06 Nov 2018 14:24:52 -0500 Received: from mail-pl1-f176.google.com ([209.85.214.176]:39032) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gK6y0-0006gg-MA for emacs-orgmode@gnu.org; Tue, 06 Nov 2018 14:24:48 -0500 Received: by mail-pl1-f176.google.com with SMTP id b5-v6so6667570pla.6 for ; Tue, 06 Nov 2018 11:24:25 -0800 (PST) In-Reply-To: <87in1btcyo.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs orgmode-mailinglist On Mon, 5 Nov 2018 at 21:46, Nicolas Goaziou wrote: > > Philip Hudson writes: > > > On Sun, 4 Nov 2018 at 14:03, Nicolas Goaziou 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 > 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 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