Re: [PATCH] Fix narrowed 1-line subtrees

[Leo Vivier <leo.vivier+org@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