nested org-headlines

nested org-headlines

[42 147]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

(1) is possible, but not (2) and (3), (3) being what I want (though (2)
would be nice).

(1)

     * HEADLINE

     Text about main topic.

     *************** INLINE TASK

     Text about tangent from main topic.

     *************** END

     Continuation of main topic.

(2)

     * HEADLINE

     Text about main topic.

     *************** INLINE TASK

     Text about tangent from main topic.

     ****************************** NESTED INLINE TASK

     Text about tangent from tangent from main topic.

     ****************************** END

     Text about tangent from main topic continued.

     *************** END

     Continuation of main topic.

(3)

     * HEADLINE

     Text about main topic.

     *************** INLINE TASK

     Text about tangent from main topic

     ** SECOND-ORDER HEADLINE ABOUT TANGENT

     Text about sub-topic mentioned in tangent

     ** ANOTHER SECOND-ORDER HEADLINE ABOUT TANGENT

     Text about a different sub-topic mentioned in tangent.

    [no return to the first-order tangent]

     *************** END

     Continuation of main topic.

[-- Attachment #2: Type: text/html, Size: 1357 bytes --]

Re: nested org-headlines

[Eric Abrahamsen]

42 147 <aeuster@gmail.com> writes:

> (1) is possible, but not (2) and (3), (3) being what I want (though
> (2)
> would be nice).

I was going to say you could use drawers instead of inline tasks (see
section 2.8 of the manual), but they don't nest properly: if you put one
inside the other and fold the outer one, it only folds to the next
:END:. So if you've got this:

#+DRAWERS: SOMEDRAWER ANOTHER
* Header

  :SOMEDRAWER:
  Some stuff.
  :ANOTHER:
  More stuff here.
  :END:
  Some more stuff.
  :END:

TAB on the top drawername gives you this:

  :SOMEDRAWER:...
  Some more stuff.
  :END:

Rather than this:

  :SOMEDRAWER:...
  :END:

Regular org uses `org-flag-drawer' for this, which just searches for the
next :END: string. I thought org elements might handle it differently,
but `org-element-drawer-parser' just does the same thing: searches for
the next :END: string.

If drawers are "greater elements" in org elements, perhaps they ought to
be able to contain other drawers? Or is non-nesting drawers a design
decision?

E

Re: nested org-headlines

[Nicolas Goaziou]

Hello,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> If drawers are "greater elements" in org elements, perhaps they ought to
> be able to contain other drawers? Or is non-nesting drawers a design
> decision?

It is a design decision.

Note that "greater element" only means that the element can contain
other elements (i.e. a paragraph.). Also, according to org-element.el
comments:

    With the exception of `headline' and `item' types, greater elements
    cannot contain other greater elements of their own type.

A drawer is a way to hide some contents (and optionally remove them from
export) without adding any specific meaning to them. What would a drawer
within another drawer mean: hide stuff even more?

Also, adding recursive drawers has a cost (for parsing speed, with
visibility cycling features...) with no real benefit, which explains why
it wasn't implemented.


Regards,

-- 
Nicolas Goaziou

Re: nested org-headlines

[Eric Abrahamsen]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> If drawers are "greater elements" in org elements, perhaps they ought to
>> be able to contain other drawers? Or is non-nesting drawers a design
>> decision?
>
> It is a design decision.
>
> Note that "greater element" only means that the element can contain
> other elements (i.e. a paragraph.). Also, according to org-element.el
> comments:
>
>     With the exception of `headline' and `item' types, greater elements
>     cannot contain other greater elements of their own type.

That's a good thing to know.

> A drawer is a way to hide some contents (and optionally remove them from
> export) without adding any specific meaning to them. What would a drawer
> within another drawer mean: hide stuff even more?

Makes plenty of sense to me. But it's not the first time someone's asked
about ways of descending from one text level into a sub-hierarchy, and
then "popping" back out to the previous textual level. When the will is
there, tools will be abused...