From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Vivier Subject: Re: [PATCH] Fix narrowed 1-line subtrees Date: Fri, 22 Feb 2019 23:04:09 +0100 Message-ID: <878sy7xyxy.fsf@hidden> References: <20190218002547.30325-1-leo.vivier@gmail.com> <87mumsqepg.fsf@nicolasgoaziou.fr> <871s44cbzb.fsf@hidden> <87sgwkoue5.fsf@nicolasgoaziou.fr> <87d0nnnbkf.fsf@hidden> <877edvn6g3.fsf@hidden> <874l8zn5vz.fsf@hidden> <87y36asiap.fsf@nicolasgoaziou.fr> <87y36atwdl.fsf@hidden> <878sy9ywwm.fsf@hidden> <8736ohywqw.fsf@hidden> <87ftsfy3l4.fsf@hidden> <87bm33y26u.fsf@hidden> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:38988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gxIvc-00065O-4w for emacs-orgmode@gnu.org; Fri, 22 Feb 2019 17:04:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gxIvZ-0005Qn-BJ for emacs-orgmode@gnu.org; Fri, 22 Feb 2019 17:04:19 -0500 Received: from mail-wm1-x344.google.com ([2a00:1450:4864:20::344]:53957) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gxIvX-0005ME-9f for emacs-orgmode@gnu.org; Fri, 22 Feb 2019 17:04:15 -0500 Received: by mail-wm1-x344.google.com with SMTP id e74so3235598wmg.3 for ; Fri, 22 Feb 2019 14:04:12 -0800 (PST) In-Reply-To: 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: Samuel Wales Cc: emacs-orgmode@gnu.org, Nicolas Goaziou Hello, Samuel Wales writes: > i have not been able to follow this conversation, but is it possible > that /all/ of this complexity is due to outline-mode's dubious choice > of not considering the final newline in an entry to be part of an > entry? I don't know much about outline-mode, but I doubt it would be the case. In my email sent on Thu, 21 Feb 2019 16:41:43 +0100, I've investigated the problem, and one of my conclusions was the following: --------------------------------[START]-------------------------------- Going back to our example, if narrowing to a 1-line subtree included that last newline, we could delete it inside our narrowed buffer. If that newline was also the beginning of a new subtree, the subtree would not be functional anymore, since we'd end up with something like this: `*Subtree 1* Subtree 2'. ---------------------------------[END]--------------------------------- So, if we kept the newline, we'd put the user at risk of breaking the following subtree. An option could be to protect that newline by modifying our deletion commands, but after having done that in a previous implementation, it'd bring its fair share of complexity. >From my point of view, I do not see it as 'complex', but rather as a different way from doing what we'd been doing so far. Most of the functions are only *slightly* modified to preserve the ambiguous newline. HTH. Best, --=20 Leo Vivier English Studies & General Linguistics Master Student, English Department Universit=C3=A9 Rennes 2