From: Michael Brand <michael.ch.brand@gmail.com>
To: Kyle Meyer <kyle@kyleam.com>
Cc: Org Mode <emacs-orgmode@gnu.org>
Subject: Re: Cut and paste an entry programmatically
Date: Sat, 29 Jun 2019 09:27:48 +0200 [thread overview]
Message-ID: <CALn3zoiKXw7TXOqf9GF6ikpmv_OTpt_oSyFKRE9AetPsDjjZ5w@mail.gmail.com> (raw)
In-Reply-To: <87lfxlky1z.fsf@kyleam.com>
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
prev parent reply other threads:[~2019-06-29 7:32 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
2019-06-29 7:27 ` Michael Brand [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=CALn3zoiKXw7TXOqf9GF6ikpmv_OTpt_oSyFKRE9AetPsDjjZ5w@mail.gmail.com \
--to=michael.ch.brand@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=kyle@kyleam.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.