Cut and paste an entry programmatically

Cut and paste an entry programmatically

[Michael Brand]

Hi all

I would like to ask for some help to understand what am I doing wrong
with this minimal complete example:

#+begin_src org
,* 1
,* 2
,* 3
,* 4
#+end_src

#+begin_src emacs-lisp :results silent
  (defun temp ()
    (org-cut-subtree)
    (org-forward-heading-same-level 2)
    (org-paste-subtree))
#+end_src

When with point on 1 you do

    M-: (progn (save-excursion (temp)) (save-excursion (temp))) RET

the resulting buffer is the expected reordered 3, 1, 2, 4. When you do

    M-: (save-excursion (temp)) RET M-: (save-excursion (temp)) RET

the resulting buffer is 3, 1, 1, 2, 4 which is not what I want (Emacs
26.1 and today's Org mode master). Why is this and how to resolve?

Michael

Re: Cut and paste an entry programmatically

[Michael Brand]

Hi all

I found something else with ~org-paste-subtree~ that surprises me and
that reminds me of ~C-c *~ where I was never able to get a remindable
understanding of what it does until now when investigating deeper with
this minimal complete example:

#+begin_src org
,* a
,** b
- x
,** c
- y
,* d
,** e
- z
,*** f
,** g
#+end_src

With point on c and ~org-paste-subtree~ the level of the new heading
is 2 but on g the level is 3. Are the different levels intended
behavior? If yes it would mean the need to add logic to
programmatically get always the same level independent of the
structure of the previous heading. If no and the level would be always
2 or always 3 I would at least not find it confusing.

With point on x and ~C-c *~ the level of the new heading is 3 as
expected by me. But on y it is 2 where I would still expect 3 with the
strong argument that y should stay within c and not be "hierarchically
moved" to a. On z the resulting level 4 seems completely off.

Michael

Fwd: Cut and paste an entry programmatically

[Michael Brand]

Hi all

I am still blocked with this issue. It looks like the content that is
pasted with the second invocation of org-paste-subtree is not just the
second org-cut-subtree but the accumulation of the first and the
second org-cut-subtree together. This MCE seems better to me than the
previous one as it does not use save-excursion:

#+begin_src emacs-lisp :results silent
  (defun temp ()
    (goto-char (point-min))
    (org-cut-subtree)
    (forward-line 2)
    (org-paste-subtree))
#+end_src

#+begin_src org
,* 1
,* 2
,* 3
,* 4
#+end_src

~M-: (temp) RET M-: (temp) RET~ results in

#+begin_src org
,* 3
,* 1
,* 1
,* 2
,* 4
#+end_src

with an unexpected reinsertion of "1" when inserting "2" resulting in
a duplicate "1".

Michael



---------- Forwarded message ---------
From: Michael Brand <michael.ch.brand@gmail.com>
Date: Thu, May 16, 2019 at 6:40 PM
Subject: Cut and paste an entry programmatically
To: Org Mode <emacs-orgmode@gnu.org>

Hi all

I would like to ask for some help to understand what am I doing wrong
with this minimal complete example:

#+begin_src org
,* 1
,* 2
,* 3
,* 4
#+end_src

#+begin_src emacs-lisp :results silent
  (defun temp ()
    (org-cut-subtree)
    (org-forward-heading-same-level 2)
    (org-paste-subtree))
#+end_src

When with point on 1 you do

    M-: (progn (save-excursion (temp)) (save-excursion (temp))) RET

the resulting buffer is the expected reordered 3, 1, 2, 4. When you do

    M-: (save-excursion (temp)) RET M-: (save-excursion (temp)) RET

the resulting buffer is 3, 1, 1, 2, 4 which is not what I want (Emacs
26.1 and today's Org mode master). Why is this and how to resolve?

Michael

Re: Cut and paste an entry programmatically

[Samuel Wales]

does (kill-new "") in front of the kill fix it?

Re: Cut and paste an entry programmatically

[Michael Brand]

Hi Samuel

On Thu, Jun 27, 2019 at 11:57 PM Samuel Wales <samologist@gmail.com> wrote:
> does (kill-new "") in front of the kill fix it?

Good idea. Yes, it prevents reinsertion of "1". Same with (setq
kill-ring nil) in front of org-cut-subtree.

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.

Michael

Re: Cut and paste an entry programmatically

[Kyle Meyer]

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

Re: Cut and paste an entry programmatically

[Michael Brand]

Hi Kyle

On Sat, Jun 29, 2019 at 2:58 AM Kyle Meyer <kyle@kyleam.com> wrote:

> 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.
> | [...]
> `----

Although I knew of course that ~C-k C-k~ appends it didn't ring the
bell it should have. And I was not aware of the concept of a "kill
command" which can make my function a "kill command", _depending on
how it is invoked_.

> 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

This is what I have been looking for, thank you.

Michael