[FEATURE REQUEST] No tangle of code blocks within archived subtrees

[FEATURE REQUEST] No tangle of code blocks within archived subtrees

[flare]

[-- Attachment #1.1: Type: text/html, Size: 7481 bytes --]

Re: [FEATURE REQUEST] No tangle of code blocks within archived subtrees

[Tom Gillespie]

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

Re: [FEATURE REQUEST] No tangle of code blocks within archived subtrees

[Bastien]

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

Re: [FEATURE REQUEST] No tangle of code blocks within archived subtrees

[Tom Gillespie]

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?

Re: [FEATURE REQUEST] No tangle of code blocks within archived subtrees

[Bastien]

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

Re: [FEATURE REQUEST] No tangle of code blocks within archived subtrees

[Tom Gillespie]

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