Marcel van der Boom <marcel <at> hsdev.com> writes: > My personal conclusion was, given proper outlining and no or very few > assumptions about indentation preferences, it would be very difficult or > confusing to implement. > > The amount of alternatives given in the thread gave me enough food for > a while to try out if those would be sufficient. So far, the inline > tasks (see below) seem to fit my need the best, although their use > feels a bit like a hack to me.
It seems like a hack to me as well. I would very much like to see this feature implemented but am not very happy with the inline task workaround. The reason inline tasks work for this purpose is that they allow for a termination string. This is also true for plain lists which terminate with two blank lines by default. It would be useful and logical to allow for a section terminator as well. This could be done very simply with a '/' character after (or before?) the appropriate number of asterisks, similar to the way html tags are terminated: * Here is a top-level heading This text follows the top level heading. ** This is a sub-section heading Here is some text within the sub-section. *** The sub-section contains an even lower level This text is part of the sub-sub-section. **/ Now we resume the top-level section. The string "**/" terminates both the 2nd and 3rd level sections. If a section terminates in this way, the next highest level continues where it left off. Section terminators would be strictly optional, sort of like </p> in html. Would this be a sensible, feasible thing to implement? I understand that it may cause difficulty for some exporters. But I don't think that org features should be limited by what other formats can easily handle, especially since there are some obvious workarounds for latex and html.
