Another old bug with org-paste-subtree. It make indentation of next heading wrong. Consider the following document and follow described steps: ---- >8 ---- #+STARTUP: indent Enable soft indent mode Put to kill ring some text *without trailing newline* that represents a subtree. In my case it is generated by a browser extension. #+begin_src elisp :results silent (kill-new "* Pasted Header\nPasted body") #+end_src Several levels of heading to make the problem apparent: * H1 ** H2 Ensure that the following "H3" heading is expanded, put cursor to this line and try =C-c C-x C-y= or [[elisp:(org-paste-subtree)]] *** H3 :PROPERTIES: :CUSTOM_ID: h3 :END: Body ---- 8< ---- Actual result: ---- >8 ---- Several levels of heading to make the problem apparent: * H1 *** H2 Ensure that the following "H3" heading is expanded, put cursor to this line and try =C-c C-x C-y= or elisp:(org-paste-subtree) ***** Pasted Header Pasted body ***** H3 :PROPERTIES: :CUSTOM_ID: h3 :END: Body ---- 8< ---- Expected result ---- >8 ---- Several levels of heading to make the problem apparent: * H1 *** H2 Ensure that the following "H3" heading is expanded, put cursor to this line and try =C-c C-x C-y= or elisp:(org-paste-subtree) ***** Pasted Header Pasted body ***** H3 :PROPERTIES: :CUSTOM_ID: h3 :END: Body ---- 8< ---- Org mode version 9.5 (release_9.5-225-g494c20
Max Nikulin <manikulin@gmail.com> writes:
> Another old bug with org-paste-subtree.
>
> It make indentation of next heading wrong.
>
> Consider the following document and follow described steps:
I am unable to reproduce on the latest Org.
Best,
Ihor
On 01/05/2022 09:31, Ihor Radchenko wrote:
> Max Nikulin writes:
>
>> Another old bug with org-paste-subtree.
>>
>> It make indentation of next heading wrong.
>>
>> Consider the following document and follow described steps:
>
> I am unable to reproduce on the latest Org.
Thank you, Ihor. I have checked it once more for current main HEAD
2bd34edb64. I can reproduce it using the provided steps in Emacs-26, but
not in Emacs-27.
Unless there is a reason to suspect something weird underneath, the
issue should be considered with rather low priority. Anyway, I have
added trailing newline to generated content and mostly use org-capture
with org-protocol for communication between applications.
fwiw [idk if this is useful but here just in case] iirc, outline mode does not include the final newline for subtrees in at least one case. yet, many users and much code assume or ensure that lines are terminated with a final newline. this can result in unexpected behavior. it required code to ensure compatibility and flexibility, and it required consideration for edge cases. sometimes the workarounds would have to be worked around by the calling code. core emacs code like sorting assumed/assumes newline. org would assume or provide none in some [but not all] cases. user or package code might naturally kill a subtree by killing the whole line when folded or killing each of the lines. those include final newline. or set require-final-newline. this is anissue for things similar to editing source blocks or capture. the usual bugs were unexpected presence or absence of newlines. idk if htat might help you debug or not. On 11/30/21, Max Nikulin <manikulin@gmail.com> wrote: > Another old bug with org-paste-subtree. > > It make indentation of next heading wrong. > > Consider the following document and follow described steps: > > ---- >8 ---- > #+STARTUP: indent > Enable soft indent mode > > Put to kill ring some text *without trailing newline* > that represents a subtree. In my case it is generated > by a browser extension. > #+begin_src elisp :results silent > (kill-new "* Pasted Header\nPasted body") > #+end_src > > Several levels of heading to make the problem apparent: > * H1 > ** H2 > Ensure that the following "H3" heading is expanded, > put cursor to this line and try =C-c C-x C-y= > or [[elisp:(org-paste-subtree)]] > *** H3 > :PROPERTIES: > :CUSTOM_ID: h3 > :END: > Body > ---- 8< ---- > > Actual result: > > ---- >8 ---- > Several levels of heading to make the problem apparent: > * H1 > *** H2 > Ensure that the following "H3" heading is expanded, > put cursor to this line and try =C-c C-x C-y= > or elisp:(org-paste-subtree) > ***** Pasted Header > Pasted body > ***** H3 > :PROPERTIES: > :CUSTOM_ID: h3 > :END: > Body > ---- 8< ---- > > Expected result > > ---- >8 ---- > Several levels of heading to make the problem apparent: > * H1 > *** H2 > Ensure that the following "H3" heading is expanded, > put cursor to this line and try =C-c C-x C-y= > or elisp:(org-paste-subtree) > ***** Pasted Header > Pasted body > ***** H3 > :PROPERTIES: > :CUSTOM_ID: h3 > :END: > Body > ---- 8< ---- > > Org mode version 9.5 (release_9.5-225-g494c20 > > > -- The Kafka Pandemic A blog about science, health, human rights, and misopathy: https://thekafkapandemic.blogspot.com
[-- Attachment #1: Type: text/plain, Size: 861 bytes --] Max Nikulin <manikulin@gmail.com> writes: >> I am unable to reproduce on the latest Org. > > Thank you, Ihor. I have checked it once more for current main HEAD > 2bd34edb64. I can reproduce it using the provided steps in Emacs-26, but > not in Emacs-27. > > Unless there is a reason to suspect something weird underneath, the > issue should be considered with rather low priority. Anyway, I have > added trailing newline to generated content and mostly use org-capture > with org-protocol for communication between applications. Thanks for the extra info! I managed to reproduce using Emacs 26 and it is a real problem with some edge case in org-indent. The problem is masked by combine-after-change-calls that is used since Emacs 27 but replaced by a placeholer in Emacs 26. The fix is attached. Let me know if it also works on your side. Best, Ihor [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-org-indent-Fix-edge-case-when-edited-region-ends-at-.patch --] [-- Type: text/x-patch, Size: 1325 bytes --] From 5dd89d7b36bee94804c7ab631780a4bd020c49cb Mon Sep 17 00:00:00 2001 Message-Id: <5dd89d7b36bee94804c7ab631780a4bd020c49cb.1651463875.git.yantar92@gmail.com> From: Ihor Radchenko <yantar92@gmail.com> Date: Mon, 2 May 2022 11:56:15 +0800 Subject: [PATCH] org-indent: Fix edge case when edited region ends at headline leading stars * lisp/org-indent.el (org-indent-refresh-maybe): Extend affected region to the whole line after END. Fixes https://orgmode.org/list/t4lpos$l3p$1@ciao.gmane.io --- lisp/org-indent.el | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/lisp/org-indent.el b/lisp/org-indent.el index 4cca0c35d..7469aba97 100644 --- a/lisp/org-indent.el +++ b/lisp/org-indent.el @@ -409,7 +409,13 @@ (defun org-indent-refresh-maybe (beg end _) (goto-char beg) (beginning-of-line) (re-search-forward - (org-with-limited-levels org-outline-regexp-bol) end t))) + (org-with-limited-levels org-outline-regexp-bol) + (save-excursion + (goto-char end) + ;; Extend to headline if END is within its + ;; headline stars. + (line-end-position)) + t))) (let ((end (save-excursion (goto-char end) (org-with-limited-levels (outline-next-heading)) -- 2.35.1
On 02/05/2022 11:00, Ihor Radchenko wrote:
> Max Nikulin writes:
>
>>> I am unable to reproduce on the latest Org.
>>
>> Thank you, Ihor. I have checked it once more for current main HEAD
>> 2bd34edb64. I can reproduce it using the provided steps in Emacs-26, but
>> not in Emacs-27.
>
> Thanks for the extra info!
> I managed to reproduce using Emacs 26 and it is a real problem with some
> edge case in org-indent. The problem is masked by
> combine-after-change-calls that is used since Emacs 27 but replaced by a
> placeholer in Emacs 26.
>
> The fix is attached. Let me know if it also works on your side.
I have not performed extensive testing, but your patch fixes the problem
at least with my test file, so thank you for digging into this issue.
that sounds like great debugging ability. was this using edebug or something?
Samuel Wales <samologist@gmail.com> writes:
> that sounds like great debugging ability. was this using edebug or something?
Just good old debug-on-entry. Nothing fancy.
Best,
Ihor
Ihor Radchenko <yantar92@gmail.com> writes:
> The fix is attached. Let me know if it also works on your side.
Fixed.
Applied onto main via 064afa0c0.
Best,
Ihor