From: Samuel Wales <samologist@gmail.com>
To: Leo Vivier <leo.vivier+org@gmail.com>
Cc: emacs-orgmode@gnu.org, Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: Re: [PATCH] Fix narrowed 1-line subtrees
Date: Fri, 22 Feb 2019 16:58:10 -0700 [thread overview]
Message-ID: <CAJcAo8uAa-7=z+992G+A-gEry_U3gi8Gxcsvw5r5pTjxhY+NWQ@mail.gmail.com> (raw)
In-Reply-To: <878sy7xyxy.fsf@hidden>
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 <leo.vivier+org@gmail.com> wrote:
> Hello,
>
> Samuel Wales <samologist@gmail.com> 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.
next prev parent reply other threads:[~2019-02-22 23:58 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 [this message]
2019-02-23 10:43 ` Leo Vivier
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='CAJcAo8uAa-7=z+992G+A-gEry_U3gi8Gxcsvw5r5pTjxhY+NWQ@mail.gmail.com' \
--to=samologist@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=leo.vivier+org@gmail.com \
--cc=mail@nicolasgoaziou.fr \
/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).