>> I guess for now I should bring the discussion to emacs-devel, since >> this is not exclusive to org mode, and see what they think. I'll >> update this thread once we decide something there > > I think this will be best. Because what you describe is not really > specific to Org mode. Eli will be in better position to comment on > the problem.
I submitted the bug to [email protected], resulting in the bug#79927 thread, which is hard to navigate in the mailing list archives but can be consulted in chronological order with this search: https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=79927&submit=Search%21&idxname=bug-gnu-emacs&max=20&result=normal&sort=date%3Aearly > This recipe does not really require org-with-point-at. > (save-excursion (goto-char ...) ...) would produce the same. First of all, this is correct, I finally was able to narrow down the bug and it can be reproduced with this form, which is not specific to org-mode: ``` (progn (switch-to-buffer "buffer-A") (setq buffer-A (current-buffer)) (setq-local window-configuration-change-hook `((lambda () (message "Hook called")))) (insert "line1\nline2\n") (setq target-marker (point-marker)) (beginning-of-buffer) (delete-other-windows) (split-window-right) (other-window 1) (switch-to-buffer "buffer-B") (with-current-buffer buffer-A (goto-char target-marker) (minibuffer-with-setup-hook (lambda () (enlarge-window 5)) (read-string "Please select enter/return key")) (setq actual-marker (point-marker))) (cl-assert (equal target-marker actual-marker) nil (format "Expected %s, actual %s" target-marker actual-marker)) ) ``` But still, even though they are considering improvements in Emacs core, the takeaway from the bug#79927 discussion is that currently you can't run arbitrary code after `with-current-buffer` + `goto-char` and expect that the point is always still were you had moved it, if that buffer was in a non selected window. In this particular case it was the interaction between `window-configuration-change-hook` and a redisplay, but a few other background processes could also force a resync of the buffer point with the window point. So I still think it's worth improving this in org-mode. Even if it's not an org-mode bug, it's a known limitation that in the specific case of org-mode it can be avoided, so I would do it. Here are a few relevant emails in the thread related to this: - https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-12/msg00171.html - https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-12/msg00179.html - https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-12/msg00193.html - https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-12/msg00448.html Please let me know what you think and if you want me to submit a patch or let it be.
