From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id aCquN3U/vmXdtAAA62LTzQ:P1 (envelope-from ) for ; Sat, 03 Feb 2024 14:28:22 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id aCquN3U/vmXdtAAA62LTzQ (envelope-from ) for ; Sat, 03 Feb 2024 14:28:22 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NoakROvv; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1706966901; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=q0XFs/7hX8cLID0VFtGaZlC4e3I0URA9AgGcfyZXChk=; b=TnIpTEdPngUVAN5+ktps12r9IFPTnCdhFr21kWU54/8SMYmGVNNurtBIUwf1mHxOu0b19W 6dvQd6uk1t+i01+yYrFTVW+W4v5aA83RXeJtSCgQc+znDFOaVA484Pw0CVPNSsoNE2Cro0 MZ6r1oy3KN/zbSbNz4Hkj5ZGpGB+xSw2Ii8AoFwQbFWwLJd9u3qmZ7X08uiaJt4fP18N9v 1AtfWdX3cj36IuYVlM4/xKWi3isqE702TLoV9rN2I4BqeSc36uQyAxAcUndZn/0cRG7zIA n53nyBYU2MMO+c8EgUE99s1asp0HNCSrE0SOwgTHKXJDi07v5s3PXjqMbH9xxA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=NoakROvv; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1706966901; a=rsa-sha256; cv=none; b=GG/aRqbx3yZHGz+voYQIQDNMpIdP55NXdg8ntygZa5cTdeu6MIVco2jy2kJ9RN97XGjIv7 WLZzVmtlsbqoHoeEiSBkMT9D2C2SeX6Xp4pJgCzGNuAWn/lxWgrYl8LlPa/wwsLIYiIQ6r 9ruasp4vmKM0mdUXzmc215x7PWXyG7Oca4SqamCyJ2V1bEVMVlaIgitIFWQ/HOQMXTIfFW 7OorJXLr/+sEHck37DhmmmDwa3PY39QuQqrGxIIk+U6LWuSIynLnBTI8Z9ESghT1+DwVno jNvw4nfOms69zANmiH9pnfS9Jj6UdDZ1MDoDl4FwIxj79ueSnb9vsjLfu5kvOA== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 8BB784306D for ; Sat, 3 Feb 2024 14:28:21 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rWG3D-0003D1-ED; Sat, 03 Feb 2024 08:27:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rWG3B-0003Ct-UR for emacs-orgmode@gnu.org; Sat, 03 Feb 2024 08:27:17 -0500 Received: from mail-yb1-xb2b.google.com ([2607:f8b0:4864:20::b2b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rWG3A-0000QG-7L for emacs-orgmode@gnu.org; Sat, 03 Feb 2024 08:27:17 -0500 Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-dc6d5206f18so2948664276.1 for ; Sat, 03 Feb 2024 05:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706966835; x=1707571635; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=q0XFs/7hX8cLID0VFtGaZlC4e3I0URA9AgGcfyZXChk=; b=NoakROvvqN0uAtkYADWteibp+eyhTpjQY8oMQLBrbWqPfNKCbzQDyYOVZSXl2eHAEx AIvKCKeL9oqCz3teL/lz55qNECasbeDBtd9I7GDodrK2hPt4bxSg9SRoBQ4hWz94l5x8 jAFAtJDZba+Cwyw1SEcZ7n8TG6J9jP3AXUvYcY/RnUpjYzMmTf3B2cdgwn+BHUjJVI2X UDgvaV6omZMJwmCzTCRAe4YpvS8dWdEng0+CQc/EPeMH6lPfA0HsY9u0rH4Ql3vs+F+D XzqSmZUtxrxk4qCPtQqwoKyeCGvutt7kRaTwtAaT6sbNdo9FlbyVR+QmEvofGszTSAh0 3qTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706966835; x=1707571635; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=q0XFs/7hX8cLID0VFtGaZlC4e3I0URA9AgGcfyZXChk=; b=OfAX/HWoJCTTF6OM6GExeJCGs8WT9ow+1S/BL6UXPb6CscY35w9phrN8Jh+8qMLYz9 LUNGALQY0qWWlp7/XFhl3BJ5X/6s1wRll8ycxgGdsMslDu2cwJBT9CiYiDOV0VWTGq2V ugIw8FK4v1h4c5cOHVmRqL5sH/Ru4AHQ7yo9WtxvmxN5qbLCaKmzCbeLV/dOCsPO4fR7 +kNHyA71xgnsg1Zbf2DHmW3Ydg7DeIRrFnX6SGRGvWA+nmONqSFlDWpAUUkgedYfOeqW A6quh91G/0TwORtTXPllmDDyaD8PKIdPSQbzmdH44RcG51vHnzHJarbm1b4/P7xgFGj9 3UpA== X-Gm-Message-State: AOJu0YzV93mI8QG83RnCN2N0KstjABA2QvRUAd5KgWu4UkQKcsUi4OVY MojFqchGkAsgv3u3LO1Dmeen1jhsAknxaH2vpQjXbIC5E6RMDdjfgJUP70Ho39mKsqvRSIQxrdL uf3r0D3QdyU+6YpBAcus/SF2QGUROF2N89t+5xw== X-Google-Smtp-Source: AGHT+IEnMowvWZW2XXUwAHRAjYIiZLcq85Z6xCICgEehQ0RsTUyxUNxi1/5bz4f8BM0XrqlPjF+ozp2xSYi5lHU08uU= X-Received: by 2002:a25:ae0c:0:b0:d80:68d1:b826 with SMTP id a12-20020a25ae0c000000b00d8068d1b826mr10545404ybj.6.1706966834721; Sat, 03 Feb 2024 05:27:14 -0800 (PST) MIME-Version: 1.0 References: <877cjl67z6.fsf@localhost> In-Reply-To: <877cjl67z6.fsf@localhost> From: gusbrs Date: Sat, 3 Feb 2024 10:27:03 -0300 Message-ID: Subject: 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/)] To: Ihor Radchenko Cc: org-mode list Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2607:f8b0:4864:20::b2b; envelope-from=gtvbrs@gmail.com; helo=mail-yb1-xb2b.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.998, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.98 X-Migadu-Scanner: mx13.migadu.com X-Spam-Score: -6.98 X-Migadu-Queue-Id: 8BB784306D X-TUID: ATh23l2AFtdd Hi Ihor, Thanks for looking into this. On Sat, 3 Feb 2024 at 09:32, Ihor Radchenko 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 ,** SubSec2 text #+end_src To here: #+begin_src org ,* Sec1 ,** SubSec1 text ,** 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- rather then C- 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 > > ** SubSec1 > > M- will yield > > * Sec1 > ** > ** 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