Suggestion/bug: Parse inlinetask "END" with level sensitivity

Suggestion/bug: Parse inlinetask "END" with level sensitivity

[Anders Johansson]

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: Suggestion/bug: Parse inlinetask "END" with level sensitivity

[Nicolas Goaziou]

Hello,

Anders Johansson <mejlaandersj@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: Suggestion/bug: Parse inlinetask "END" with level sensitivity

[Anders Johansson]

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 <mejlaandersj@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,
>