From: Kyle Meyer <kyle@kyleam.com>
To: Michael Brand <michael.ch.brand@gmail.com>,
Samuel Wales <samologist@gmail.com>
Cc: Org Mode <emacs-orgmode@gnu.org>
Subject: Re: Cut and paste an entry programmatically
Date: Fri, 28 Jun 2019 20:58:00 -0400 [thread overview]
Message-ID: <87lfxlky1z.fsf@kyleam.com> (raw)
In-Reply-To: <CALn3zog12GqR=9Xi+TxqGO70tE4Z-i3Q4f-0FUQyHbXhq-9mKw@mail.gmail.com>
Michael Brand <michael.ch.brand@gmail.com> writes:
[...]
> With your idea I debug printed kill-ring and found that after the
> second invocation of org-cut-subtree during ~M-: (temp) RET M-: (temp)
> RET~ it consists of only one list element with a string containing
> both 1 and 2 instead of one list element with only 1 and another with
> only 2. So to me this looks like a bug in org-cut-subtree.
Hmm I don't consider that a bug. It's documented behavior for kill
commands to append to the last kill when called successively.
,----[ C-h f kill-region RET ]
| [...]
| Any command that calls this function is a "kill command".
| If the previous command was also a kill command,
| the text killed this time appends to the text killed last time
| to make one entry in the kill ring.
| [...]
`----
To get a better feel for what's happening, I'd suggest evaluating
kill-region with C-u C-M-x and stepping through its execution.
In addition to what Samuel posted, another way for a lisp caller to
avoid the append behavior if desired is to let-bind this-command so that
kill-region's attempt to set it to kill-region doesn't work. Using your
example, that'd be
#+begin_src emacs-lisp
(defun temp ()
(let (this-command)
(org-cut-subtree))
(org-forward-heading-same-level 2)
(org-paste-subtree))
#+end_src
--
Kyle
next prev parent reply other threads:[~2019-06-29 0:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-16 16:40 Cut and paste an entry programmatically Michael Brand
2019-05-17 10:16 ` Michael Brand
2019-06-27 13:50 ` Fwd: " Michael Brand
2019-06-27 21:57 ` Samuel Wales
2019-06-28 11:07 ` Michael Brand
2019-06-29 0:58 ` Kyle Meyer [this message]
2019-06-29 7:27 ` Michael Brand
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=87lfxlky1z.fsf@kyleam.com \
--to=kyle@kyleam.com \
--cc=emacs-orgmode@gnu.org \
--cc=michael.ch.brand@gmail.com \
--cc=samologist@gmail.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 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).