From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Wales Subject: Re: [PATCH] Fix narrowed 1-line subtrees Date: Fri, 22 Feb 2019 16:58:10 -0700 Message-ID: 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> <878sy7xyxy.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]:52754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gxKiE-0005cI-Eq for emacs-orgmode@gnu.org; Fri, 22 Feb 2019 18:58:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gxKiD-0002c0-Eq for emacs-orgmode@gnu.org; Fri, 22 Feb 2019 18:58:38 -0500 Received: from mail-lf1-x141.google.com ([2a00:1450:4864:20::141]:34455) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gxKiD-0002Ii-2q for emacs-orgmode@gnu.org; Fri, 22 Feb 2019 18:58:37 -0500 Received: by mail-lf1-x141.google.com with SMTP id u21so3025633lfu.1 for ; Fri, 22 Feb 2019 15:58:12 -0800 (PST) In-Reply-To: <878sy7xyxy.fsf@hidden> 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, Nicolas Goaziou ok, i can't follow this so thanks for the comments. i'll trust that you know what you are doing. however, fyi, long ago, i discovered various bugs in this newline area, most of which were trackable to outline mode's decision to define an entry as ending before its final newline. most users and many writers of code are likely to mark a region by going to bol, not eol. they don't likely think the region should end before the final newline, in most cases. but org calls some outline function or two that grabs or narrows to or marks a region that is shorter by 1 char than imo it should be. i reported one bug, which joined two lines [including headers], that had remained unfixed for many years. this is probably because noticing certain types of data corruption /at the time of corruption/ can sometimes be tricky. thus, linking it to user behavior or org code changes can be tricky and the bug report would be like "um, i have no mwe but...". in this particular case, when you did find joined lines, it was likely to be long after the corruption. [low s/n.] the problem was that when you sorted headers in a narrowed region, it joined lines. the region was off by one because the outline function is [imo] off by one. it would not surprise me if long-term users checked their files now for joined lines, such as headers, they'd find old corruption. On 2/22/19, Leo Vivier wrote: > 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, > -- > Leo Vivier > English Studies & General Linguistics > Master Student, English Department > Universit=C3=A9 Rennes 2 > --=20 The Kafka Pandemic: What is misopathy? https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged= .html The disease DOES progress. MANY people have died from it. And ANYBODY can get it at any time.