From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Vivier Subject: [PATCH] org.el: Fix newline at eob in org-insert-heading Date: Mon, 11 Feb 2019 15:40:14 +0100 Message-ID: <20190211144014.22930-1-zaephon@gmail.com> References: <20190211133813.4348-1-zaephon@gmail.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([209.51.188.92]:43397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gtCl7-0007ZL-1S for emacs-orgmode@gnu.org; Mon, 11 Feb 2019 09:40:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gtCl0-000577-Dz for emacs-orgmode@gnu.org; Mon, 11 Feb 2019 09:40:28 -0500 Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]:35270) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gtCl0-000554-4G for emacs-orgmode@gnu.org; Mon, 11 Feb 2019 09:40:26 -0500 Received: by mail-wr1-x432.google.com with SMTP id t18so626551wrx.2 for ; Mon, 11 Feb 2019 06:40:26 -0800 (PST) In-Reply-To: <20190211133813.4348-1-zaephon@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: emacs-orgmode@gnu.org Cc: Leo Vivier * lisp/org.el (org-insert-heading): Check if narrowed before inserting newline at eob When narrowed into an org-buffer (e.g. when capturing), adding a new heading with C- or M- on the last line of a buffer (i.e. that not without a newline at the end) would result in the insertion of a newline at the bottom of the narrowed capture buffer. - C-: `org-insert-heading-respect-content' - M-: `org-meta-return' Both functions use `org-insert-heading' in their definitions. The problem is due to `eobp' returning t when point is on the last character of the narrowed buffer (as explained in its docstring). Since those `eobp' predicates in `org-insert-heading' are probably there to ensure a newline at the end of the *file*, checking whether we are at the end of the *widened* buffer prior to inserting the newline fixes the problem. The patch I'd originally submitted failed to address narrowed buffer whose `(max-pos)` was also that of the widened buffer. Rather than using `(buffer-narrowed-p)`, I opted for a `(widen)` followed by `(eobp)`. TINYCHANGE --- I was able to replicate the problem with `emacs -q`, so the problem doesn't seem to come from custom options in my own setup. The problematic lines were inserted in the following commit: b16feed40c7f519ada0cd9315251dcc257be31d2 . Their goal was to C- more predictable, and I don't think I've modified that behaviour in a any way. Let me know if you'd rather have me squash the changes. lisp/org.el | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 7e74c2199..fef13f818 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7542,8 +7542,9 @@ unconditionally." (unless (and blank? (org-previous-line-empty-p)) (org-N-empty-lines-before-current (if blank? 1 0))) (insert stars " ") - (when (and (eobp) - (not (buffer-narrowed-p))) + (when (save-restriction + (widen) + (eobp)) (save-excursion (insert "\n"))) ;; When INVISIBLE-OK is non-nil, ensure newly created headline ;; is visible. @@ -7572,15 +7573,17 @@ unconditionally." (when blank? (insert "\n")) (insert "\n" stars " ") (when (org-string-nw-p split) (insert split)) - (when (and (eobp) - (not (buffer-narrowed-p))) + (when (save-restriction + (widen) + (eobp)) (save-excursion (insert "\n"))))) (t (end-of-line) (when blank? (insert "\n")) (insert "\n" stars " ") - (when (and (eobp) - (not (buffer-narrowed-p))) + (when (save-restriction + (widen) + (eobp)) (save-excursion (insert "\n")))))) ;; On regular text, turn line into a headline or split, if ;; appropriate. -- 2.20.1