* Cut and paste an entry programmatically
@ 2019-05-16 16:40 Michael Brand
2019-05-17 10:16 ` Michael Brand
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Michael Brand @ 2019-05-16 16:40 UTC (permalink / raw)
To: Org Mode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cut and paste an entry programmatically
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
2 siblings, 0 replies; 7+ messages in thread
From: Michael Brand @ 2019-05-17 10:16 UTC (permalink / raw)
To: Org Mode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Fwd: Cut and paste an entry programmatically
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 ` Michael Brand
2019-06-27 21:57 ` Samuel Wales
2 siblings, 0 replies; 7+ messages in thread
From: Michael Brand @ 2019-06-27 13:50 UTC (permalink / raw)
To: Org Mode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cut and paste an entry programmatically
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
2 siblings, 1 reply; 7+ messages in thread
From: Samuel Wales @ 2019-06-27 21:57 UTC (permalink / raw)
To: Michael Brand; +Cc: Org Mode
does (kill-new "") in front of the kill fix it?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cut and paste an entry programmatically
2019-06-27 21:57 ` Samuel Wales
@ 2019-06-28 11:07 ` Michael Brand
2019-06-29 0:58 ` Kyle Meyer
0 siblings, 1 reply; 7+ messages in thread
From: Michael Brand @ 2019-06-28 11:07 UTC (permalink / raw)
To: Samuel Wales; +Cc: Org Mode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cut and paste an entry programmatically
2019-06-28 11:07 ` Michael Brand
@ 2019-06-29 0:58 ` Kyle Meyer
2019-06-29 7:27 ` Michael Brand
0 siblings, 1 reply; 7+ messages in thread
From: Kyle Meyer @ 2019-06-29 0:58 UTC (permalink / raw)
To: Michael Brand, Samuel Wales; +Cc: Org Mode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cut and paste an entry programmatically
2019-06-29 0:58 ` Kyle Meyer
@ 2019-06-29 7:27 ` Michael Brand
0 siblings, 0 replies; 7+ messages in thread
From: Michael Brand @ 2019-06-29 7:27 UTC (permalink / raw)
To: Kyle Meyer; +Cc: Org Mode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-06-29 7:32 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2019-06-29 7:27 ` Michael Brand
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).