From: Leo Vivier <leo.vivier+org@gmail.com>
To: Samuel Wales <samologist@gmail.com>
Cc: emacs-orgmode@gnu.org, Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: Re: [PATCH] Fix narrowed 1-line subtrees
Date: Sat, 23 Feb 2019 11:43:23 +0100 [thread overview]
Message-ID: <875ztazsxg.fsf@hidden> (raw)
In-Reply-To: <CAJcAo8uAa-7=z+992G+A-gEry_U3gi8Gxcsvw5r5pTjxhY+NWQ@mail.gmail.com>
Hello,
Samuel Wales <samologist@gmail.com> 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,
--
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2
prev parent reply other threads:[~2019-02-23 10:56 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-18 0:25 [PATCH 1/2] Fix narrowing for 1-line subtrees Leo Vivier
2019-02-18 0:25 ` [PATCH 2/2] Prevent deletion of newline added by narrowing Leo Vivier
2019-02-18 1:02 ` [PATCH] Fix other commands for exiting narrowing Leo Vivier
2019-02-18 1:21 ` [PATCH] Fix other commands for exiting narrowing (2) Leo Vivier
2019-02-18 17:18 ` [PATCH] Fix problems Leo Vivier
2019-02-19 10:01 ` [PATCH 1/2] Fix narrowing for 1-line subtrees Nicolas Goaziou
2019-02-19 10:24 ` Leo Vivier
2019-02-19 10:35 ` [PATCH] Fix narrowing for 1-line subtrees (squashed) Leo Vivier
2019-02-19 12:05 ` [PATCH 1/2] Fix narrowing for 1-line subtrees Nicolas Goaziou
2019-02-19 13:37 ` Leo Vivier
2019-02-19 15:28 ` Leo Vivier
2019-02-19 15:40 ` Leo Vivier
2019-02-20 13:25 ` Nicolas Goaziou
2019-02-20 13:36 ` Leo Vivier
2019-02-21 15:38 ` [PATCH] Fix narrowed " Leo Vivier
2019-02-21 15:41 ` Leo Vivier
2019-02-21 15:43 ` [PATCH] Fix spaces with `org-remove-timestamp-with-keyword' Leo Vivier
2019-02-22 20:23 ` [PATCH] Fix narrowed 1-line subtrees Leo Vivier
2019-02-22 20:54 ` Leo Vivier
2019-02-22 21:53 ` Samuel Wales
2019-02-22 22:04 ` Leo Vivier
2019-02-22 23:58 ` Samuel Wales
2019-02-23 10:43 ` Leo Vivier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875ztazsxg.fsf@hidden \
--to=leo.vivier+org@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
--cc=samologist@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).