Re: [BUG] org-insert-heading changed behavior with Emacs 29.2 [9.6.15 (release_9.6.15 @ /usr/local/share/emacs/29.2/lisp/org/)]

[gusbrs <gusbrs.2016@gmail.com>]

Hi Ihor,

Thanks for looking into this.

On Sat, 3 Feb 2024 at 09:32, Ihor Radchenko <yantar92@posteo.net> wrote:

> The number of blank lines after newly inserted is not defined by Org
> mode, unlike the number of blank lines before heading that is controlled
> by `org-blank-before-new-entry'.

Well, "not defined" is strong, I'd say. There is no exposed option.
But the behavior used to be regular, and "do the right thing" (OK, you
may wish to debate that). And now the behavior has changed.

The commit basically only changes from:

    (org-end-of-subtree)

to:

     (org-end-of-subtree invisible-ok 'to-heading)

Which essentially changes the point position before the task of
actually inserting the heading is carried out.

It goes from here:

#+begin_src org
,* Sec1

,** SubSec1

text<point>

,** SubSec2

text

#+end_src

To here:

#+begin_src org
,* Sec1

,** SubSec1

text

,<point>** SubSec2

text

#+end_src

In practice, the previous behavior would "honor" whatever blank lines
existed in the current heading. That's why
`org-blank-before-new-entry' was needed, but something like
`org-blank-after-new-entry' not so much. Consistency was naturally
kept, because of this regularity.

> If you use M-<RET> rather then C-<RET> and set
> (setq org-blank-before-new-entry '((heading) (plain-list-item)))
> , you will get no newlines after the new heading inserted before current:
>
> * Sec1
>
> ** <point>SubSec1
>
> M-<RET> will yield
>
> * Sec1
> ** <point>
> ** SubSec1

Not the same thing, C-RET calls `org-insert-heading-respect-content'
and `org-meta-return' calls `org-insert-heading'. Besides, what we get
seems to align with what you asked in `org-blank-before-new-entry'. I
tend to use mostly C-RET, because it is more regular, and I use lists
a lot, so that's the issue I'm raising.

> Would it make sense to add a new `org-blank-after-new-entry'
> customization that will provide explicit user control over what Org does
> when inserting a new heading?

Looking from the perspective of C-RET alone, I'd be inclined to
restate my suggestion of treating the issue that motivated that commit
as a "visibility / folding" problem. However, including M-RET into the
mix, I think you have a good point, and something like
`org-blank-after-new-entry' would possibly help improve blank line
consistency in general.

Best regards,
gusbrs