Sebastian Miele <i...@whxvd.name> writes: > I first reported this to bug-gnu-em...@gnu.org (see > https://debbugs.gnu.org/65734). However, Eli asks: > >> I'm not sure I understand why this is deemed a problem in Emacs. >> Shouldn't Org redefine C-S-<backspace> if the default binding doesn't >> suit what happens in Org buffers? Did you discuss this with Org >> developers?
Confirmed. I am CCing debbugs as I'd like to clarify things to be in sync with Emacs. > In an emacs -Q, create an Org buffer with the following contents: > > --8<---------------cut here---------------start------------->8--- > * AB > ** C > --8<---------------cut here---------------end--------------->8--- This will produce * AB... > Fold the subtree under the heading AB, so that only a single line is > displayed (ending in "..."). With point between A and B, hit > C-S-<backspace> (kill-whole-line). > > Expected: The whole _visible_ line, i.e., the entire contents of the > buffer is erased. Actual behavior: The line with heading C remains. This indeed happens because `kill-whole-line' deletes the line in two steps: "* A" and then the rest. The first deletion leaves B<begin invisible> ** C<end invisible> which drastically alters the outline structure and triggers or to automatically unfold the subtree, leaving B ** C visible. Then, `kill-whole-line' proceeds with the second part of the deletion and deletes the now visible line, leading to the observed behaviour. The first deletion would be an equivalent of deleting "(defun" (defun foo ()... in outline-mode and would make it hard to unfold the body, if such single deletion where performed. In Org mode, because of frequent user requests about accidental deletions of hidden text, we try our best to protect deletions of invisible folded outlines. Automatic unfolding is one of the ways to attract user's attention to potential accidental edit. > Contrast this with the same experiment, except that the point is at the > beginning of the line containing AB when hitting C-S-<backspace>. Then > the expected behavior happens. According to the source of > kill-whole-line, the intended effect indeed is to kill a whole _visible_ > line. Currently, Org mode, similar to Eli's suggestion re-binds `kill-line' to Org's own version - `org-kill-line'. But not `kill-whole-line'. We can certainly do the same for `kill-whole-line', but in our previous discussion https://yhetil.org/emacs-devel/87tu8rq2l6.fsf@localhost/, you asked to consider extending the built-in Emacs commands instead of overriding them. As I described in the above, Org needs more control over the behaviour of `kill-line'/`kill-whole-line' when the visible line contains multiple lines of hidden text - to protect accidental deletions. A hook, where Org can intervene with a yes/no prompt, would be useful. It would also make sense to group the two edits together via `combine-after-change-calls', although a more universal way to know that certain edits are a part of the same known command (even when called non-interactively) would be useful. In addition, `org-kill-line' acts specially in certain scenarios: For * Heading <point> text :tag1:tag2: `org-kill-line' will keep and re-align ":tag1:tag2:": * Heading <point> :tag1:tag2: It would be nice if we could express such behavior without overriding the `kill-line' command. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
