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 command
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 and
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 i
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
,*
