Re: [O] [PATCH] Fix narrowed 1-line subtrees

[Samuel Wales]

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 <address@hidden> wrote:
> Hello,
>
> Samuel Wales <address@hidden> 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é Rennes 2
>


-- 
The Kafka Pandemic: <http://thekafkapandemic.blogspot.com>

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.