From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.bugs,gmane.emacs.orgmode Subject: bug#65734: [BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)] Date: Tue, 05 Sep 2023 10:29:20 +0000 Message-ID: <87tts8vrpb.fsf@localhost> References: <87il8pao4l.fsf@whxvd.name> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18328"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 65734@debbugs.gnu.org, emacs-orgmode@gnu.org To: Sebastian Miele Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 05 12:29:24 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qdTJE-0004XC-5V for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 05 Sep 2023 12:29:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qdTIt-0006ZA-9A; Tue, 05 Sep 2023 06:29:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qdTIr-0006Yj-WC for bug-gnu-emacs@gnu.org; Tue, 05 Sep 2023 06:29:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qdTIr-0001kR-OD for bug-gnu-emacs@gnu.org; Tue, 05 Sep 2023 06:29:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qdTIs-0007MF-4C for bug-gnu-emacs@gnu.org; Tue, 05 Sep 2023 06:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Sep 2023 10:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65734 X-GNU-PR-Package: emacs Original-Received: via spool by 65734-submit@debbugs.gnu.org id=B65734.169390972228258 (code B ref 65734); Tue, 05 Sep 2023 10:29:02 +0000 Original-Received: (at 65734) by debbugs.gnu.org; 5 Sep 2023 10:28:42 +0000 Original-Received: from localhost ([127.0.0.1]:54125 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdTIY-0007Li-77 for submit@debbugs.gnu.org; Tue, 05 Sep 2023 06:28:42 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:45905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdTIU-0007LT-Pj for 65734@debbugs.gnu.org; Tue, 05 Sep 2023 06:28:40 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 5DFA3240027 for <65734@debbugs.gnu.org>; Tue, 5 Sep 2023 12:28:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1693909712; bh=8Ah3fNK74InKWYUdXrhkbtS79qxkX3g3JM3vIBnS/tQ=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=fvr6vd3OsTvPJ0dPiGV8RusGR2Gaao9z9eETXKgginJAZLQj/ciXYGAb3cK/uiSSs /AIbhawcdEupgnp31UB8JyJdzYklo6FeTG2kho6+VYm4qv93v4yTLGHbhEU5o9fQt3 WTnGM4BeHsGVkDViXXXdX2HSqwrHZVwkcwl0KBz6koalkhrr9sdCghio2/1xjUlt1W uK6AM3z+rFnkFez2ED8rUM8Hrp61jikPWAc0fgWgIxpQ/BcX0TnB6a9Dgc+/ceZLYF aNkakYq2RAAveRcTNTjKrAjcZDr7DtRKD3TB7KE54k5s99i9HQTK2Sm0RM3I9ugR29 IYmDgs8JjfGnw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Rg1tl2WVnz6trs; Tue, 5 Sep 2023 12:28:31 +0200 (CEST) In-Reply-To: <87il8pao4l.fsf@whxvd.name> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:269338 gmane.emacs.orgmode:157096 Archived-At: Sebastian Miele writes: > I first reported this to bug-gnu-emacs@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- 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- (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 ** C 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-. 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 text :tag1:tag2: `org-kill-line' will keep and re-align ":tag1:tag2:": * Heading :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 . Support Org development at , or support my work at