From: David Maus <dmaus@ictsoc.de>
To: Matt Lundin <mdl@imapmail.org>
Cc: David Maus <dmaus@ictsoc.de>, Org Mode <emacs-orgmode@gnu.org>,
Sebastien Vauban <wxhgmqzgwmuf@spammotel.com>
Subject: Re: org-paste-subtree and org-refile broken
Date: Sat, 20 Aug 2011 20:41:24 +0200 [thread overview]
Message-ID: <87liuoj57v.wl%dmaus@ictsoc.de> (raw)
In-Reply-To: <87ty9lpfwj.fsf@fastmail.fm>
[-- Attachment #1: Type: text/plain, Size: 4334 bytes --]
At Sat, 13 Aug 2011 09:03:40 -0500,
Matt Lundin wrote:
>
> David Maus <dmaus@ictsoc.de> writes:
>
> > At Sat, 13 Aug 2011 09:25:19 +0200,
> > David Maus wrote:
> >>
> >> Hi Matt,
> >> Hi Sebastien,
> >>
> >> I pushed a temporary workaround to master that should fix the problem
> >> with refile and capture. Both depend on a buggy behavior of
> >> org-paste-subtree, i.e. pasting a subtree *above* the target headline
> >> when called with point at the beginning of the target headline.
> >
> > If you have already pulled, please pull again. Had confused something,
> > fixed now.
>
> Thanks for fixing this! Refiling is working well now. Could you explain
> what you mean by a "buggy behavior of org-paste-subtree." AFAIK,
> org-paste-subtree has always pasted the subtree above the current tree
> if the point is at the beginning of the headline. Is there something in
> the documentation that suggests that this should not be the case? I
> believe this behavior is consistent with
> org-insert-heading-respect-content, which inserts a new heading above
> the current heading if called at the beginning of a headline. For
> instance, in the following example...
>
> --8<---------------cut here---------------start------------->8---
> * One
> Text in one
> * Two
> Text in two
> ** Subpoint two
> Text in subpoint two.
> * Three
> Text in three
> * Four
> Text in four
> --8<---------------cut here---------------end--------------->8---
>
> If I kill headline four, move the point to the beginning of headline
> three, and yank (i.e., call org-paste-subtree), I get the following,
> which seems to me correct:
>
> --8<---------------cut here---------------start------------->8---
> * One
> Text in one
> * Two
> Text in two
> ** Subpoint two
> Text in subpoint two.
> * Four
> Text in four
>
> * Three
> Text in three
> --8<---------------cut here---------------end--------------->8---
>
> Similarly, if I place the cursor on three and call
> org-insert-heading-respect-content (M-RET), the new headline is inserted
> above the headline:
>
> --8<---------------cut here---------------start------------->8---
> * One
> Text in one
> * Two
> Text in two
> ** Subpoint two
> Text in subpoint two.
> *
> * Three
> Text in three
> * Four
> Text in four
> --8<---------------cut here---------------end--------------->8---
>
What bothers me is the fact that paste-subtree operates on the
previous sibling of a headline if called with explicit level and point
at the beginning of a headline.
--8<---------------cut here---------------start------------->8---
* One
Text in one
* Two
Text in two
** Subpoint two
Text in subpoint two.
* Three
Text in three
* Four
Text in four
--8<---------------cut here---------------end--------------->8---
Cut Four, move point at the beginning of Three and paste with a level
of 2 (C-u 2 C-c C-x C-y) and you get:
--8<---------------cut here---------------start------------->8---
* One
Text in one
* Two
Text in two
** Subpoint two
Text in subpoint two.
** Four
Text in four
* Three
Text in three
--8<---------------cut here---------------end--------------->8---
For refile this means that if you refile Four to Two, refile operates
on Two by operating on Two's following-sibling, Three.
There seems to be no practical problem, it's
just... strange. Especially if you consider pasting a subtree with
point somewhere on a headline but not at the beginning. Here []
represents point.
--8<---------------cut here---------------start------------->8---
* One
Text in one
* T[]wo
Text in two
** Subpoint two
Text in subpoint two.
* Three
Text in three
--8<---------------cut here---------------end--------------->8---
I've noticed that Org did not cover this case, e.g. calculated the
paste level correctly but pasted above. What I expected Org to do in
this case is to paste the subtree as last child of Two. If this
expectation is implemented (I am on it) then pasting above if point is
at beginning of headline is strange because point is still on the
heading but the direction of paste is reversed. It's not a practical
problem if the subtree is pasted with the same level as the target
headline (i.e. its sibling), but still...
Best,
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de
[-- Attachment #2: Type: application/pgp-signature, Size: 230 bytes --]
prev parent reply other threads:[~2011-08-20 18:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-13 3:31 org-paste-subtree and org-refile broken Matt Lundin
2011-08-13 3:36 ` Matt Lundin
2011-08-13 7:25 ` David Maus
2011-08-13 13:05 ` David Maus
2011-08-13 14:03 ` Matt Lundin
2011-08-20 18:41 ` David Maus [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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87liuoj57v.wl%dmaus@ictsoc.de \
--to=dmaus@ictsoc.de \
--cc=emacs-orgmode@gnu.org \
--cc=mdl@imapmail.org \
--cc=wxhgmqzgwmuf@spammotel.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.