> The bug you reported is a consequence of the function mostly > designed for interactive use. > If you use it interactively, it will be unexpected to sort invisible > heading at point. Users will rather expect the nearest visible heading > to be the subtree being sorted. > > I think that we condition your change depending on whether the function > is called interactively or not.
Done, here is the updated patch:
>From 0cc3f50856c290942b66c1d43b7b488e80724eec Mon Sep 17 00:00:00 2001 From: Ignacio Casso <[email protected]> Date: Wed, 29 Apr 2026 10:28:01 +0200 Subject: [PATCH] org.el: fix `org-sort-entries' bug when heading at point not visible * lisp/org.el (org-sort-entries): Consider invisible text when moving back to heading. Otherwise if the heading at point is not visible, the function will not sort that heading but its closest visible parent. Link: https://list.orgmode.org/orgmode/[email protected] --- lisp/org.el | 4 +-- testing/lisp/test-org.el | 54 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index cb36497f4..b8ed6ef30 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -8085,9 +8085,9 @@ function is being called interactively." what "region") (goto-char start)) ((or (org-at-heading-p) - (ignore-errors (progn (org-back-to-heading) t))) + (ignore-errors (progn (org-back-to-heading (not interactive?)) t))) ;; we will sort the children of the current headline - (org-back-to-heading) + (org-back-to-heading (not interactive?)) (setq start (point) end (progn (org-end-of-subtree t t) (or (bolp) (insert "\n")) diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index 4ba7aa560..8aaea5e0b 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -4101,6 +4101,60 @@ SCHEDULED: <2017-05-06 Sat> "\n* B\n* A\n# Local Variables:\n# foo: t\n# End:" (org-sort-entries nil ?a) (buffer-string)))) + ;; Sort invisible entries when called non-interactively + (should + (equal " +* Top +** B +** A +*** 1 +*** 2 +*** 3 +** C +" + (org-test-with-temp-text + " +* Top +** B +** A +*** 1 +*** 3 +*** 2 +** C +" + (org-overview) + (goto-char 13) + (org-sort-entries nil ?a) + (buffer-string) + ))) + ;; Sort closest visible entry when called interactively + (should + (equal " +* Top +** A +*** 1 +*** 3 +*** 2 +** B +** C +" + (org-test-with-temp-text + " +* Top +** B +** A +*** 1 +*** 3 +*** 2 +** C +" + (org-overview) + (goto-char 13) + (let ((unread-command-events (listify-key-sequence (kbd "a")))) + (call-interactively 'org-sort-entries)) + (buffer-string) + ))) + ;; Sort region (should (equal " -- 2.43.0
> Also, there is similar inconsistency with active region. I expect bugs there. What do you mean? Anyway, my new fix doesn't change the behavior with active regions. If the function is called interactively, nothing changes, and if it's call not interactively and the active region is hidden, the command was already failing with a "org-sort-entries: Region to sort contains a level above the first entry" error. That is probably a bug on its own, but it's not the only one I've seen with active regions when trying to understand your comment. For example, this file with this active region ``` ;; Beginning of region *B ** 1 ** 2 *A ** X ;; End of region ** Y ``` is sorted to ``` * A ** X ;; * B ** 1 ** 2 ** Y ``` I would leave active regions out of the scope of this fix.
