From: Leo Vivier <leo.vivier+org@gmail.com>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Fix narrowed 1-line subtrees
Date: Thu, 21 Feb 2019 16:41:43 +0100 [thread overview]
Message-ID: <8736ohywqw.fsf@hidden> (raw)
In-Reply-To: <878sy9ywwm.fsf@hidden>
Hello,
Here’s a detailed account of the problem and solution of the patch
I’ve just sent.
I don’t have the time to write the tests today, but I’ll get on it as
soon as I can.
-----------------------------------------------------------------------
This patch addresses multiple issues occuring when running commands on
a 1-line subtree when the buffer is narrowed to it. A 1-line subtree
is a subtree only containing a heading and a newline at the end.
The problem is due to the way narrowing works in Emacs. It requires a
region defined by two bounds on which to anchor the narrowing. The
bounds respectively become the `point-min' and `point-max of the
narrowed buffer.
As the content within the narrowed region evolves, `point-max' is
pushed or shrinked to accommodate the modifications to the content.
Since a position within a buffer in Emacs is defined as the number of
characters between the top of the file (whose value is 1) and `point',
that means that everything after `point-max' evolves in unisson with
the narrowed buffer.
For example, in an org-mode buffer narrowed to a subtree, adding a
newline at the end of a heading adds 1 character to the buffer
which then pushes `point-max' *and* everything after it in the widened
buffer by 1.
The problem occurs when the bounds of the region to narrow are
ambiguous, as is the case with 1-line subtrees. When you narrow an
org-mode buffer to a 1-line subtree, the end of the line becomes
`point-max'. Remembering our definition of a 1-line subtree above,
you might wonder why we're not including the newline, but the reason
is simple: that newline might also belong to another subtree.
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'.
-----------------------------------------------------------------------
Example:
--------------------------------[START]--------------------------------
* Tree 1
:PROPERTIES:
:TEST: t
:END:
* Tree 2
---------------------------------[END]---------------------------------
With point on `Tree 1', run the following:
(progn
(org-narrow-to-subtree)
(org-delete-property "TEST")
(org-back-to-heading)
(end-of-line)
(delete-char 1)
(widen))
Result:
--------------------------------[START]--------------------------------
* Tree 1* Tree 2
---------------------------------[END]---------------------------------
Observation:
The newline between the two headings has been removed despite the fact
that it wasn't in the buffer restriction.
-----------------------------------------------------------------------
This ambiguous newline causes a lot of unexpected behaviours with
commands inserting or removing content, e.g. clocking, scheduling as
well as manipulating deadlines, properties, etc.
Some of those commands act on a widened buffer which prevents them
from inadvertently deleting that newline. That's the case for
clocking in a task, since it adds `CLOCK:' lines below the heading at
point.
However, because those commands act on a widened buffer, they do not
have access to the narrowed buffer's `point-max'. The consequence is
that, when the restriction of the buffer is restored after
`save-restriction', the narrowing function sees that the content
between `point-min' and `point-max' hasn't changed (there's still a
newline at the end) and restores the region as if nothing had happened.
The command worked, but there's no way to see it in the narrowed
buffer.
Another example of an unexpected behaviour with commands acting on a
widened buffer is when the command creates a 1-line subtree. That's
the case when removing a :PROPERTIES: drawer. When the command
removes the content *and* the last newline, upon restoring the
restriction, `point-max' is seen to have shrunk, and becomes the first
character which hasn't changed, which is the newline after the
heading. The problem is that this is the ambiguous newline we
discussed above, and that deleting it could break the following
subtree if there was any.
The solution to this problem is to ensure that those commands never
act beyond the `point-max' of the narrowed buffer even when working in
the widened buffer.
As an example, when clocking in a task, rather than inserting a
newline *after* the last char which isn't part of the heading,
i.e. the ambiguous newline, we insert it after the last unambiguous
character. This works because when narrowing, as we saw,
`point-max' *is* that unambiguous character, and adding characters
before it simply pushes `point-max' by as many characters as you've
inserted, and this is tracked by `save-restriction'.
This happens because `save-restriction' adds a special property
to *all* the characters within the current restriction, not only
`point-min' and `point-max'. Upon restoring the previous restriction,
`save-restriction' looks for those special characters and try to
include them all inside the new restriction. Practically, this is
done by looking for the first and last characters with that special
property and using them as the new `point-min' and `point-max'.
This last bit is important to understand why the second example with
the :PROPERTIES: drawer didn't behave properly. The original command
deletes the drawer from the ambiguous newline to the bottom of the
heading, which means that the newline at the end of the heading isn't
touched. When `save-restriction' attempts to resume the previous
narrowing, since the former `point-max' has been deleted (it was the
`:' at the end of the :PROPERTIES: drawer), it looks for the first
special character. But the problem is that this first character is the
bottom of the heading, and that it has now become ambiguous.
The solution is the same: we do not touch the ambiguous newline.
Instead, we delete the newline at the end of the heading so that upon
restoring the restriction, it becomes the last special character.
Visually, instead of deleting the following bracketed region...
--------------------------------[START]--------------------------------
* Tree 1
{:PROPERTIES:
:TEST: t
:END:
}* Tree 2
---------------------------------[END]---------------------------------
We delete the following one:
--------------------------------[START]--------------------------------
* Tree 1{
:PROPERTIES:
:TEST: t
:END:}
* Tree 2
---------------------------------[END]---------------------------------
It's likely that I haven't addressed all the commands that do not play
well with the ambiguous newlines. However, the solutions I've
presented here should be enough to address them.
-----------------------------------------------------------------------
HTH
Best,
--
Leo Vivier
English Studies & General Linguistics
Master Student, English Department
Université Rennes 2
next prev parent reply other threads:[~2019-02-21 15:41 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 [this message]
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
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=8736ohywqw.fsf@hidden \
--to=leo.vivier+org@gmail.com \
--cc=emacs-orgmode@gnu.org \
--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).