> We cannot use `without-restriction' because it is only available since > Emacs 29, while we still support Emacs 28.
Got it! Will use (save-restriction (widen) ...) instead. > More importantly, this will likely break > 44e7ed1a59c8587c2d5c3a54917576f1505a6c7b that purposely calls > `narrow-to-subtree'. Your `without-restriction' removes that > narrowing. I don't really use datetrees, and don't know the reasoning for `org-narrow-to-subtree' there. I worry I might break it without understanding. But anyways, I think it makes sense to place the `save-restriction' starting before the `org-narrow-to-subtree' and ending when we exit the archive buffer, so I don't see how it would conflict with the narrow to subtree. To me, losing narrowing is quite jarring, and I think its worth figuring out a way to keep it preserved. > If we look into bf09955fec57307616926959b31e19af42520db0, it introduced > `org-fold-show-all' to fix the following: > > The bug was this: when inserting an entry at the end of an archive > buffer, the entry would get folded within the previous entry fold. > This prevented the entry to get the proper DONE keyword when required. Even deleting the `org-fold-show-all' I was not able to recreate the bug mentioned in that commit. However, there is also a call to `org-fold-show-subtree', which I don't think should be removed. For this reason, it may still make sense to wrap everything with `org-fold-core-save-visibility'. HOWEVER, I realize now that `org-fold-core-save-visibility' is anyways not ideal, because the newly archived heading will not be folded in any case. It leads to a half open tree. In fact, a possibly better solution is to not worry about preserving folding and instead, at the end of archiving, fold closed the archive subtree. It seems that one wouldn't typically want to look at a heading that was just archived. Well, if that would break other people's workflow, we could leave it as is, but this last option would be my preference. I attach a new patch, although I'm happy to keep updating it as required. Best, Benjamin On Wed, Jul 23, 2025 at 3:20 AM Ihor Radchenko <yanta...@posteo.net> wrote: > Benjamin McMillan <mcmilla...@gmail.com> writes: > > > Ihor, I don't quite understand your remark about the two previous > patches, > > are they something I need to take into account in this patch? > > Yes. More specifically, you should make sure that the commits I linked > to are not broken by your patch. > > > Although the commit only changes a couple of lines, there are large > blocks > > whose indentation changes. > > The non-whitespace changes are > > 1) to add a without-restriction as soon as buffer switches to archive > > buffer. > > > 3) Delete a call to widen, which had become redundant. > > We cannot use `without-restriction' because it is only available since > Emacs 29, while we still support Emacs 28. > > More importantly, this will likely break > 44e7ed1a59c8587c2d5c3a54917576f1505a6c7b that purposely calls > `narrow-to-subtree'. Your `without-restriction' removes that > narrowing. > > > 2) to wrap the call to org-fold-show-all in that buffer with an > > org-fold-core-save-visibility > > If we look into bf09955fec57307616926959b31e19af42520db0, it introduced > `org-fold-show-all' to fix the following: > > The bug was this: when inserting an entry at the end of an archive > buffer, the entry would get folded within the previous entry fold. > This prevented the entry to get the proper DONE keyword when required. > > This change also kill the archive buffer after archiving. > > I do not think that this bug is reported on the mailing list (at least, > I was unable to find anything), and, generally, folding state should not > affect todo keyword setting. So, we should likely just remove the call > to `org-fold-show-all'. But please double-check. > > -- > 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
