Ihor Radchenko <[email protected]> writes:

> Yup. If we make org-babel-execute-subtree skip commented subtrees, we
> will still have org-babel-execute-block do it if it is directly called
> inside a commented subtree.

We could also check. For example, I did a quick experiment with
org-babel-tangle, and if I narrow an Org buffer to a child of a
commented tree and try to tangle, it ignores it.

> AFAIU, the logic behind comments is that they affect things when Org
> document is converted to other format - via export to via tangling.
> The comments are used for internal notes from the author that are not
> intended for publishing the final document.
>
> Of course, the notion of comment can be interpreted differently by
> different users. This is probably the reason why we have things like
> org-agenda-skip-comment-trees (defaulting to t!).
>
> I think the easiest thing that we can improve is the documentation in
> this area.

Agree, the issue was just that I had different expectations and
assumptions for the COMMENT keyword behavior, so it's better to just
document it. If it was originally introduced just for exporting and we
tried to do something like `org-agenda-skip-comment-trees` here, we
would only strengthen the idea that comments are supposed to make the
tree be ignored for all intents and purposes, and we would just be
moving the issue to the next feature were that assumption doesn't really
hold.

When I have time, I'll take a look at the documentation and see what
can be improved to clarify it, and I'll submit a patch.

> I guess we might have a customization affecting
> org-babel-execute-subtree, but there is already :eval no that can be set
> tree-wide.

:eval header argument is enough for me now that I know that this isn't
a bug, and I guess it's enough for everyone else too once this is
documented better.

Reply via email to