This is a patch to fix my previous report of a regression in capture behavior between 9.3 and 9.3.6:
> Basically, the last position in the narrowed org-capture is actually > the first position on the next line, so when you go to (end-of-buffer) > and start typing you start clobbering the next headline. The fix already landed in cb2774d1a is inadequate for me as the subtree structure can still be broken during the capture process. I think this is the more correct approach, though I haven't done much testing outside of my own workflow and `make test`. It seems to be the same behavior as 9.3.
>From e6f4faacd2db9ea3f5dc6d6582e0e58ee11c8bef Mon Sep 17 00:00:00 2001 From: nivekuil <m...@nivekuil.com> Date: Fri, 29 May 2020 16:48:31 -0700 Subject: [PATCH] Fix org-capture-narrow --- lisp/org-capture.el | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/lisp/org-capture.el b/lisp/org-capture.el index 9136d331b..4d2c3e8d4 100644 --- a/lisp/org-capture.el +++ b/lisp/org-capture.el @@ -728,16 +728,6 @@ captured item after finalizing." (run-hooks 'org-capture-prepare-finalize-hook) - ;; Fix missing final newline, as it may have been deleted by accident - (when (eq (org-capture-get :type 'local) 'entry) - (save-excursion - (goto-char (point-max)) - (and (not (looking-at-p "^")) - (org-with-wide-buffer - (and (not (looking-at-p org-heading-regexp)) - (not (eobp)))) - (insert "\n")))) - ;; Did we start the clock in this capture buffer? (when (and org-capture-clock-was-started org-clock-marker @@ -1166,7 +1156,7 @@ may have been stored before." (org-capture-empty-lines-after) (unless (org-at-heading-p) (outline-next-heading)) (org-capture-mark-kill-region origin (point)) - (org-capture-narrow beg (point)) + (org-capture-narrow beg (if (eobp) (point) (1- (point)))) (org-capture--position-cursor beg (point)))))) (defun org-capture-place-item () -- 2.26.2
