[O] Suggestion/bug: Parse inlinetask END with level sensitivity
Hi. I recently started using inlinetasks to be able to tag and comment long texts (a kind of simple qualitative data analysis). I thought that I would be able to use both tasks with and without an END line interchangeably: *** inlinetask without end some text *** inlinetask with end text inside inlinetask *** END The problem (not so surprising really) is that the parser finds the END of the second inlinetask and makes them nested in an export. I thought this could be solved with using different numbers of stars for tasks with and without END, judging from these lines in org-inlinetask.el: ;; If you need to have a time planning line (DEADLINE etc), drawers, ;; for example LOGBOOK of PROPERTIES, or even normal text as part of ;; the inline task, you must add an END headline with the same ;; number of stars. But the search for END in the parser is actually star-insensitive so this didn't solve my problem either. I suggest requiring the END-line to contain as many stars as it's beginning line by doing something like this (there is certainly a cleaner way doing it) to org-element-inlinetask-parser: @@ -972,7 +972,9 @@ plist (task-end (save-excursion (end-of-line) - (and (re-search-forward ^\\*+ END limit t) + (and (re-search-forward + (concat ^ (mapconcat 'identity (make-list (nth 1 components) \\*) ) END) + limit t) (match-beginning 0 (contents-begin (progn (forward-line) (and task-end ( (point) task-end) (point But perhaps this is too unstable? (Although it could be expected from the comments above). Cheers, Anders Johansson
Re: [O] Suggestion/bug: Parse inlinetask END with level sensitivity
Hello, Anders Johansson mejlaande...@gmail.com writes: I thought that I would be able to use both tasks with and without an END line interchangeably: *** inlinetask without end some text *** inlinetask with end text inside inlinetask *** END The problem (not so surprising really) is that the parser finds the END of the second inlinetask and makes them nested in an export. This should be fixed in maint. Thank you for reporting it. For the record, inlinetasks cannot be nested, and the number of stars is not meaningful, as long as it is greater than `org-inlinetask-min-level'. Regards, -- Nicolas Goaziou
Re: [O] Suggestion/bug: Parse inlinetask END with level sensitivity
Great! Taking a look at your solution I realize where the bug lay as well. Level is unimportant, it just scanned too long previously (it should only look if the next headline contains END, not look for the next headline with END). Regards, Anders Johansson Den mån 17 feb 2014 23:05:02 skrev Nicolas Goaziou: Hello, Anders Johansson mejlaande...@gmail.com writes: I thought that I would be able to use both tasks with and without an END line interchangeably: *** inlinetask without end some text *** inlinetask with end text inside inlinetask *** END The problem (not so surprising really) is that the parser finds the END of the second inlinetask and makes them nested in an export. This should be fixed in maint. Thank you for reporting it. For the record, inlinetasks cannot be nested, and the number of stars is not meaningful, as long as it is greater than `org-inlinetask-min-level'. Regards,
