Re: [FR] Add org-delete-subtree without modifying the kill ring

[Pedro Andres Aranda Gutierrez]

You could replace kill-region with extract-delete-region and putting the returned string in the kill ring if kill-region was intended or discarding the string if not. /PA Enviado desde mi iPhone El 15 ago 2026, a las 8:23, Dr. Michael Hailer <dr.hai...@proton.me> escribió:  Thanks! extract-delete-region is a good point, especially if the operation were factored into something reusable internally. For a plain org-delete-subtree, I suppose delete-region expresses the intent most directly, since the deleted contents aren’t needed afterwards. But having an extraction primitive could certainly be useful for other subtree operations. Regards Michael -------- Original Message -------- On Saturday, 08/15/26 at 08:17 Pedro Andres Aranda Gutierrez <paag...@gmail.com> wrote: That’s what I do to move lines around without impacting the kill-ring. Actually I use extract-delete-region, just in case you want to do something else with the region you are deleting… /PA Enviado desde mi iPhone El 14 ago 2026, a las 17:36, Dr. Michael Hailer <dr.hai...@proton.me> escribió:  Hi, a recent discussion brought up the question of how to delete an Org subtree without modifying the kill ring. Org already provides org-cut-subtree, but there does not appear to be a corresponding command for simply deleting a subtree. One workaround is to call org-cut-subtree and then modify the kill ring afterwards, but that seems undesirable since the intention is not to kill the subtree in the first place. Would an org-delete-subtree command be useful in Org core? Conceptually, a simple implementation could be along these lines: (defun org-delete-subtree (&optional n)   "Delete the current subtree without adding it to the kill ring. With prefix arg N, delete this many sequential subtrees."   (interactive "p" org-mode)   ;; Determine the region occupied by N subtrees and delete it   ;; using `delete-region' instead of `kill-region'.   ...) I left out the detailed implementation here deliberately, since org-copy-subtree already handles a number of details such as sequential subtrees, inline tasks, and markers, and it may be preferable to share some of that machinery rather than duplicate it. The intended distinction would simply be: org-cut-subtree: remove the subtree and put it into the kill ring org-delete-subtree: remove the subtree without touching the kill ring Does this sound like functionality that would be appropriate for Org itself? Best regards, Michael Hailer <publickey - dr.hai...@proton.me - 0x0D521D34.asc> <publickey - dr.hai...@proton.me - 0x0D521D34.asc>