Hi Gabriel, This seems like it is probably a bug given that everything else about archive headings is disabled. In the meantime, depending on how many blocks you are dealing with you could hack around this by using the following header argument. #+header: :tangle (unless-archived "/ssh:host:/path/to/file") The implementation of unless-archived is below along with a demo org file. Best! Tom * Bootstrap This is a giant hack which only works because the state of Emacs when resolving the tangle header is sitting on the block in question which I'm guessing is an implementation detail. #+begin_src elisp (defun unless-archived (path) (save-excursion (if (let ((heading (outline-previous-heading)) archived) (while (and (not archived) heading) (let ((element (org-element-at-point))) (setq archived (org-element-property :archivedp element))) (setq heading (ignore-errors (outline-up-heading 1))) (message "%s" heading)) archived) "no" path))) #+end_src * sysadmin ** some server I don't use anymore :ARCHIVE: *** distractor heading *** tangled code in here #+header: :tangle (unless-archived "/ssh:localhost:/tmp/some-file.sh") #+begin_src bash "yes this tangles when archived" #+end_src
Hi Tom,
Tom Gillespie <tgbugs@gmail.com> writes:
> This seems like it is probably a bug given that everything else
> about archive headings is disabled.
Yes, I agree this should considered as a bug.
I have a fix for it, which is to ignore archived subtrees along with
commented ones when tangling.
org-in-commented-heading-p is used in these Babel functions:
- org-babel-exp-process-buffer
- org-babel-ref-resolve
- org-babel-expand-noweb-references
Should we treat archived subtrees like commented ones in these
contexts too? Respectively when exporting, resolving refs and
expanding noweb references?
I'd favor such an equal treatment of commented/archived subtrees but
I'd like to make sure it sounds good to everyone before.
--
Bastien
Hi Bastien, My initial reaction was to say yes to all of these in the name of consistency, but there are nuances for org-babel-ref-resolve and org-babel-expand-noweb-references that are different than for org-babel-exp-process-buffer. If I have a block that nowebbs in another block, and at some point that other block is archived, do we treat it as if the block never existed? I don't think we do. Same for org-babel-ref-resolve. Those names exist and we know they exist, we just don't display/export them. I'm basing this on the assumption that users who archive headings don't want to see them/search them, not that they wanted to remove them entirely or refactor things related to them. It might make sense to warn if a block that is nowebbed in has been archived so the user can do something about it if they want, but I think having archiving effectively induce a null pointer is a bad idea. I wonder what other perspectives there are on this. Best! Tom On Sun, Sep 6, 2020 at 2:37 AM Bastien <bzg@gnu.org> wrote: > - org-babel-exp-process-buffer Yes > - org-babel-ref-resolve Probably not? > - org-babel-expand-noweb-references Probably not?
Thanks Tom for the feedback.
>> - org-babel-exp-process-buffer
> Yes
>> - org-babel-ref-resolve
> Probably not?
>> - org-babel-expand-noweb-references
> Probably not?
I've done this in master now, see 9f0af69dd2.
Best,
--
Bastien
Great, thank you. Also handy to see the "right" way to traverse up the
tree. Best!
Tom
On Sun, Sep 6, 2020 at 9:52 PM Bastien <bzg@gnu.org> wrote:
>
> Thanks Tom for the feedback.
>
> >> - org-babel-exp-process-buffer
> > Yes
> >> - org-babel-ref-resolve
> > Probably not?
> >> - org-babel-expand-noweb-references
> > Probably not?
>
> I've done this in master now, see 9f0af69dd2.
>
> Best,
>
> --
> Bastien