* 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/)]
@ 2018-10-29 22:47 Philip Hudson
2018-11-01 10:04 ` Philip Hudson
2018-11-01 21:34 ` Nicolas Goaziou
0 siblings, 2 replies; 14+ messages in thread
From: Philip Hudson @ 2018-10-29 22:47 UTC (permalink / raw)
To: emacs orgmode-mailinglist
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
^ permalink raw reply [flat|nested] 14+ messages in thread* 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/)] 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 1 sibling, 0 replies; 14+ messages in thread From: Philip Hudson @ 2018-11-01 10:04 UTC (permalink / raw) To: emacs orgmode-mailinglist 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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/)] 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 1 sibling, 1 reply; 14+ messages in thread From: Nicolas Goaziou @ 2018-11-01 21:34 UTC (permalink / raw) To: Philip Hudson; +Cc: emacs orgmode-mailinglist 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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/)] 2018-11-01 21:34 ` Nicolas Goaziou @ 2018-11-02 0:24 ` Philip Hudson 2018-11-02 1:35 ` Nicolas Goaziou 0 siblings, 1 reply; 14+ messages in thread From: Philip Hudson @ 2018-11-02 0:24 UTC (permalink / raw) To: emacs orgmode-mailinglist 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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/)] 2018-11-02 0:24 ` Philip Hudson @ 2018-11-02 1:35 ` Nicolas Goaziou 2018-11-02 9:22 ` Philip Hudson 0 siblings, 1 reply; 14+ messages in thread From: Nicolas Goaziou @ 2018-11-02 1:35 UTC (permalink / raw) To: Philip Hudson; +Cc: emacs orgmode-mailinglist 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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/)] 2018-11-02 1:35 ` Nicolas Goaziou @ 2018-11-02 9:22 ` Philip Hudson 2018-11-03 8:34 ` Nicolas Goaziou 0 siblings, 1 reply; 14+ messages in thread From: Philip Hudson @ 2018-11-02 9:22 UTC (permalink / raw) To: emacs orgmode-mailinglist 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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/)] 2018-11-02 9:22 ` Philip Hudson @ 2018-11-03 8:34 ` Nicolas Goaziou 2018-11-03 9:09 ` Philip Hudson 0 siblings, 1 reply; 14+ messages in thread From: Nicolas Goaziou @ 2018-11-03 8:34 UTC (permalink / raw) To: Philip Hudson; +Cc: emacs orgmode-mailinglist 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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/)] 2018-11-03 8:34 ` Nicolas Goaziou @ 2018-11-03 9:09 ` Philip Hudson 2018-11-04 14:03 ` Nicolas Goaziou 0 siblings, 1 reply; 14+ messages in thread From: Philip Hudson @ 2018-11-03 9:09 UTC (permalink / raw) To: emacs orgmode-mailinglist 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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/)] 2018-11-03 9:09 ` Philip Hudson @ 2018-11-04 14:03 ` Nicolas Goaziou 2018-11-04 16:31 ` Philip Hudson 0 siblings, 1 reply; 14+ messages in thread From: Nicolas Goaziou @ 2018-11-04 14:03 UTC (permalink / raw) To: Philip Hudson; +Cc: emacs orgmode-mailinglist 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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/)] 2018-11-04 14:03 ` Nicolas Goaziou @ 2018-11-04 16:31 ` Philip Hudson 2018-11-05 21:46 ` Nicolas Goaziou 0 siblings, 1 reply; 14+ messages in thread From: Philip Hudson @ 2018-11-04 16:31 UTC (permalink / raw) To: emacs orgmode-mailinglist 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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/)] 2018-11-04 16:31 ` Philip Hudson @ 2018-11-05 21:46 ` Nicolas Goaziou 2018-11-06 19:24 ` Philip Hudson 0 siblings, 1 reply; 14+ messages in thread From: Nicolas Goaziou @ 2018-11-05 21:46 UTC (permalink / raw) To: Philip Hudson; +Cc: emacs orgmode-mailinglist 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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/)] 2018-11-05 21:46 ` Nicolas Goaziou @ 2018-11-06 19:24 ` Philip Hudson 2018-11-10 10:39 ` Nicolas Goaziou 0 siblings, 1 reply; 14+ messages in thread From: Philip Hudson @ 2018-11-06 19:24 UTC (permalink / raw) To: emacs orgmode-mailinglist 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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/)] 2018-11-06 19:24 ` Philip Hudson @ 2018-11-10 10:39 ` Nicolas Goaziou 2018-11-10 15:06 ` Philip Hudson 0 siblings, 1 reply; 14+ messages in thread From: Nicolas Goaziou @ 2018-11-10 10:39 UTC (permalink / raw) To: Philip Hudson; +Cc: emacs orgmode-mailinglist 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* 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/)] 2018-11-10 10:39 ` Nicolas Goaziou @ 2018-11-10 15:06 ` Philip Hudson 0 siblings, 0 replies; 14+ messages in thread From: Philip Hudson @ 2018-11-10 15:06 UTC (permalink / raw) To: emacs orgmode-mailinglist 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2018-11-10 15:17 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 2018-11-10 10:39 ` Nicolas Goaziou 2018-11-10 15:06 ` Philip Hudson
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).