Hi Kyle
On Sat, Jun 29, 2019 at 2:58 AM Kyle Meyer 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
Michael Brand 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
Hi Samuel
On Thu, Jun 27, 2019 at 11:57 PM Samuel Wales 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
does (kill-new "") in front of the kill fix it?
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
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)
