Michael Brand <michael.ch.br...@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