From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [PATCH] org.el: Fix newline at eob in org-insert-heading Date: Sat, 16 Feb 2019 09:38:55 +0100 Message-ID: <878sygp1pc.fsf@nicolasgoaziou.fr> References: <20190211133813.4348-1-zaephon@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([209.51.188.92]:60223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1guvV3-0004gc-DM for emacs-orgmode@gnu.org; Sat, 16 Feb 2019 03:39:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1guvV2-0006Ne-Np for emacs-orgmode@gnu.org; Sat, 16 Feb 2019 03:39:05 -0500 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:35887) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1guvV2-0006Du-I3 for emacs-orgmode@gnu.org; Sat, 16 Feb 2019 03:39:04 -0500 In-Reply-To: <20190211133813.4348-1-zaephon@gmail.com> (Leo Vivier's message of "Mon, 11 Feb 2019 14:38:13 +0100") 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: Leo Vivier Cc: emacs-orgmode@gnu.org Hello, Leo Vivier writes: > * 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 > the buffer is *narrowed* (with `buffer-narrowed-p') prior to inserting > the newline fixes the problem. I don't think this would be a sufficient fix, because the buffer can be narrowed and, yet, showing the end of the file. Anyway, I don't think this final newline is needed. I removed it. This should fix your issue. Please let me know if you encounter other glitches in that area. Regards, -- Nicolas Goaziou