Hi Ihor, Thanks for looking into this.
On Sat, 3 Feb 2024 at 09:32, Ihor Radchenko <yanta...@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