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 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,
Re: [O] Suggestion/bug: Parse inlinetask "END" with level sensitivity
Hello, Anders Johansson 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
[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
