I see. I don't follow the reasoning, but I'm happy to leave it as is. I do want to point out, in case the issue is revisited in the future, that `org-archive-to-archive-sibling' does explicitly fold the archive tree at the end, and so does end with the entire archived-to tree folded.
I attach a patch that simply uses a call to `org-with-wide-buffer' to preserve the narrowing state, and deletes the call to `org-fold-show-all'. It leaves the archived subtree dangling, but this doesn't bother me personally, because I don't see it when narrowed to some other subtree. On Sun, Aug 3, 2025 at 8:12 PM Ihor Radchenko <yanta...@posteo.net> wrote: > Benjamin McMillan <mcmilla...@gmail.com> writes: > > >> But that will do exactly the opposite of what `org-fold-show-subtree' > > does, won't it? > > > > I thought `org-fold-show-subtree' was there because various later > > commands wouldn't work well if the tree was folded. In which case > > it could be closed when done. Is that not the purpose? > > There is no detailed description of this particular line in the git > history, but judging from the code it was not added because commands > won't work on invisible regions. The comment ";; Make the subtree visible" > also implies that it is intentional. > > So, it looks like making sure that the archived subtree is visible is > intentional from the very beginning. > > -- > Ihor Radchenko // yantar92, > Org mode maintainer, > Learn more about Org mode at <https://orgmode.org/>. > Support Org development at <https://liberapay.com/org-mode>, > or support my work at <https://liberapay.com/yantar92> >
0001-org-archive.el-Fix-issue-archiving-subtree-to-same-f.patch
Description: Binary data
