From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id GGZXNBYD92SCHQAA9RJhRA:P1 (envelope-from ) for ; Tue, 05 Sep 2023 12:29:43 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id GGZXNBYD92SCHQAA9RJhRA (envelope-from ) for ; Tue, 05 Sep 2023 12:29:42 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 73AE6BDB2 for ; Tue, 5 Sep 2023 12:29:42 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=fvr6vd3O; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1693909782; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=eYRJthR7QmedvinDnkTet+B+AJrof2aKVHZ0J2LbPrk=; b=WqY7OzsVroC0eVQjPDpakQeVz6XzqmoQU/8S5Lrp7Wuikjp68gzQfvFIaILMwVxC85AM0F Gh7kQDf4fBeijbGC0o4b++M0Ru8FG1onIpCqgHMX7mIBmv95mqxo7PFgu+Itah+hYN33Ip i2wrZfYxFVfnfsPUtdBctaHQrBXy1G+SUiT1mig+pW01NyqTd1IwqAfysefp2zzV5IeIcI 1fl+ejRT1wAQf0Fa74spDf+OAD6lB7iN9pwJGfSK2E7YOmqcMo63PBcYAkdKSuNkadn5K/ RjfzxLYksPc4LYl6zgn+C1mR7PVVgCjFnhwTkswqfMVhZQ/mrhJb3ExrRTf3Lg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693909782; a=rsa-sha256; cv=none; b=JBTE1/cj0W/7q5Faclzzyn9GU3SxcZ9kX4hgrhUDBInauwwR04efQqOkQnJrSxfLX2p7Yn sGcMhzYnQ9EgJ7D3qsdU86ahyIM11wFnNFobeTMkNyOJlJdK0sW26HIap4HFqEwh2zqyl+ McIXvQS6mMERScJa4Dghzoz6tIuA56NjjEDgzbiuIOt/+225MzT2ETb4VNPQFL5efMvvNe EHaS4S4WpjEtzFtMsIRqlbqDviH5ZS/aihbaDcoLi3vKiUPmTIgVMwq3uTu9ev6QkziA0s RZYPLDxBOwTgynXEBQyLpVe++xJ0aTpRIkG2rtLrrukPTxvu94qxTvxN3seP1w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=fvr6vd3O; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qdTIh-0006Xq-KY; Tue, 05 Sep 2023 06:28:53 -0400 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 1qdTIW-0006Vw-P0 for emacs-orgmode@gnu.org; Tue, 05 Sep 2023 06:28:41 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qdTIQ-0001h5-3u for emacs-orgmode@gnu.org; Tue, 05 Sep 2023 06:28:40 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 39566240029 for ; 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== 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) From: Ihor Radchenko To: Sebastian Miele Cc: emacs-orgmode@gnu.org, 65734@debbugs.gnu.org Subject: Re: [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/)] In-Reply-To: <87il8pao4l.fsf@whxvd.name> References: <87il8pao4l.fsf@whxvd.name> Date: Tue, 05 Sep 2023 10:29:20 +0000 Message-ID: <87tts8vrpb.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Scanner: mx0.migadu.com X-Migadu-Spam-Score: -9.44 X-Spam-Score: -9.44 X-Migadu-Queue-Id: 73AE6BDB2 X-TUID: gSrL6ORKn41q 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