From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Vivier Subject: Re: [PATCH] Fix narrowed 1-line subtrees Date: Sat, 23 Feb 2019 11:43:23 +0100 Message-ID: <875ztazsxg.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> <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]:54059) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gxUyR-0002SH-7w for emacs-orgmode@gnu.org; Sat, 23 Feb 2019 05:56:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gxUmN-0004Hb-BK for emacs-orgmode@gnu.org; Sat, 23 Feb 2019 05:43:36 -0500 Received: from mail-wr1-x441.google.com ([2a00:1450:4864:20::441]:34992) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gxUmN-00041j-1V for emacs-orgmode@gnu.org; Sat, 23 Feb 2019 05:43:35 -0500 Received: by mail-wr1-x441.google.com with SMTP id t18so4977989wrx.2 for ; Sat, 23 Feb 2019 02:43:27 -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: > 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. I don't know about most users, but that's what I do. It's easier to mark the beginning of a region and then `forward-line' your way to the end of the region. > 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'm not sure. It might be a case of Stockholm syndrome, but I've found that not including the final newline in the narrowed subtree holds some semantic value, especially when you like to keep your .org files tight with only 1 newline between two headings, i.e. `*Tree 1^J*Tree 2'. When `(org-end-of-subtree t)' lands you somewhere where the hl-line does not extend to the right fringe, it means that you (or a misbehaving commands) haven't introduced any spurious newline. > 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...". Thank you for your insight. I think this is something we could address with an arsenal of tests. The idea would be to run in a narrowed subtree all the commands which would add or remove content below it. Then, we widen the buffer and check whether the following tree has been corrupted. I'll get on it as soon as I can. > 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. Maybe we could add a function to `org-lint' which would throw a warning when a regex like "\\(\\sw\\|\\s.\\)\\(\\* .*$\\)" matches something. With the following structure: --------------------------------[START]-------------------------------- * Test 1* Corrupted 1 * Test 2 With text in the body.* Corrupted 2 * Test 3 * Not corrupted ---------------------------------[END]--------------------------------- The regex correctly matches `Corrupted 1' and `Corrupted 2', but we'd obviously need to find a way to make it safer. But as it stands, it could be used as a way to address past corruptions. So, to recap: 1. We address *potential corruptions* by adding more tests in order to catch them before they get a chance to corrupt anything. 2. We address *past corruptions* by adding a function to `org-lint' which catches corrupted subtrees and throw a warning. HTH. Best, --=20 Leo Vivier English Studies & General Linguistics Master Student, English Department Universit=C3=A9 Rennes 2