Mark Edgington <edgi...@gmail.com> writes: > Eric Abrahamsen <eric <at> ericabrahamsen.net> writes: >> >> It looks like a groundswell for remove-andor-promote tags for headlines, >> but for the sake of argument let me propose the use of blocks. It seems >> to me that something like a "generic block" (a block that does nothing >> but delete its begin/end delimiters on export) fits the use-case better: >> > > Consider the following: > > * Test > > #+begin_block abc > * test2 > #+begin_block def > * test3 > ** test4 > #+end_block > > ** test5 > #+end_block
FWIW, I think the above example is actually illegal Org syntax -- it's going to result in breakage in many ways, not just this case. > Some remarks on this, and on blocks vs. headlines: > > - For me, the above example ends up being indented very poorly with > org-indent-mode active. Also folding the nested headlines swallows up the > end-block lines. > > - I find that it's difficult to identify what belongs to what block, and the > need to have both start and end lines to delineate the blocks is a bit more > noisy and can be a pain to work with (what if I want to remove the "abc > frame" -- I will need not only to delete the begin line, but also to locate > where the corresponding end line is, and delete it as well). > > - creating a block (manually, at least) requires more effort than creating a > headline (= more RSI). > > - It also may be convenient at times to be able to remove the :promote:, > etc. tags in order to have the exporter include the grouping as part of the > exported document's structure. > > - Likewise, what if I want to add a :noexport: tag so that all of the > content is ignored -- easy with headlines, more work to do the same thing > with a block. Yup, I don't really have any argument against these above points -- I think it's mostly a matter of use-case. The inconvenience of the block approach could easily be remedied with a few extra functions: something like org-wrap-region-in-block and org-delete-enclosing-block would probably do it. But your second two objections are just a matter of a difference in use-case: you want something more flexible and powerful. My suggestion is just a lighter-weight alternate if (it's a possibility) the tag-based approach gets nixed... E
