From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 WBhbJT8X92Ti/QAAG6o9tA:P1 (envelope-from ) for ; Tue, 05 Sep 2023 13:55: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 mp10.migadu.com with LMTPS id WBhbJT8X92Ti/QAAG6o9tA (envelope-from ) for ; Tue, 05 Sep 2023 13:55:43 +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 5C1D733795 for ; Tue, 5 Sep 2023 13:55:43 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=cSthk9Eh; 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=gnu.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1693914943; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=ctXI1vAgVua1DQvvuF/IvtUNvDeBYd0bzAqagmg8kgQ=; b=WLdTlalr27GX8Q7BDTskhN7rEVw4fj4SqXFAakpy5BluuyVe5Eedyq1oQSFrPScUWYmZDz DvaUtYL5eswea4S9UU2Q25gxvMSdsKa/lmpDLuiqdFETjyqsokCv3qnCGgIY4YnyWd4I29 +4hO7o/tKEj2xrulghpKypn5ZKQftben85neYfh1B8ZZfPqxossNkaSRk0FDmKjIvQ0N69 0bcOCQmnXDJv212iCLTMIeDWZF8jBLFWtu4HplwUCeOGWLWmmkn6cbCTXyVs0JRdZenS1G KYLENfngFiiPawLoyR4KOnEb8bEYmlBehLNq8dTNC/xuVcxtSGoHc0RvyAvlHg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693914943; a=rsa-sha256; cv=none; b=d2YxeLGVtOJ5O7rigw5OgisAoNGqbBy726pcRDwLKmA9qnoFQrsO2uxNrV8r3RsENNtoYb 3CA/ALQyx86tcpMgNND+k3oJ/JfH/Qbk/YY8908lSPiHZWsvezXEPzm+2Eu5KclwQowvMv 5ylrdWe6q1YuFGTycEfs6Bdgkibk5nnngFmHIsdD+09Cc4FEIV3LS8OkZv9uKBDmpB2a3i lrSpwJr80AdmfLxuaKEmfvUtfU0yN9GPg55bINt9KSog47yHSduZKFxHBprNGsXdmDgTTL 6VaG6DevRtZ6NuQTQ0FSuHQejPyDbyWgszmsV9fzTMsPXw0HIdeyKe0EONHK8w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=cSthk9Eh; 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=gnu.org Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qdUdq-0003ry-CD; Tue, 05 Sep 2023 07:54:46 -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 1qdUdp-0003rY-Be for emacs-orgmode@gnu.org; Tue, 05 Sep 2023 07:54:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qdUdo-0002OK-UX; Tue, 05 Sep 2023 07:54:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ctXI1vAgVua1DQvvuF/IvtUNvDeBYd0bzAqagmg8kgQ=; b=cSthk9Eh5b53 iSbCjSEWtiXN5OSY3SYkBZ/R86opoBABFT3sIsAOjLCbcda+jnlhjP+AU378IL+HjyeVAHDwTqiMD 3/EpYYiiQSBLqmnLAba1nRgCAhs09fHlCnitJSF4b1N13ydA8yPjn6Ohxd3rPRV1iofM/cm6DGbM5 fEVxo8b7cdP2L74ZxifupgBVfPCSp0y3+Btp32CWsXZRl7DgwzHVZe/sVpF5BMBVrlDg9ClcvxWFu Lxs6qmwqOMh0AHSlIMag4jycwW41ao/AFCeFEZfBexdPD0iYeP0/HAOwkjmWCVCeFvA47C37xD/6X 6jwAi526Vjn2SXltcbeJkQ==; Date: Tue, 05 Sep 2023 14:54:26 +0300 Message-Id: <83h6o84yz1.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko Cc: iota@whxvd.name, 65734@debbugs.gnu.org, emacs-orgmode@gnu.org In-Reply-To: <87tts8vrpb.fsf@localhost> (message from Ihor Radchenko on Tue, 05 Sep 2023 10:29:20 +0000) Subject: Re: 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/)] References: <87il8pao4l.fsf@whxvd.name> <87tts8vrpb.fsf@localhost> 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: -7.97 X-Spam-Score: -7.97 X-Migadu-Queue-Id: 5C1D733795 X-TUID: Y1Xzwd8mzMqq > Cc: 65734@debbugs.gnu.org, emacs-orgmode@gnu.org > From: Ihor Radchenko > Date: Tue, 05 Sep 2023 10:29:20 +0000 > > 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. The command kills in two parts for a good reason, which is explained in the comments to the code. So making a single group will not work, I think, at least not in all situations. And relying on after-change hooks to fix this use case sounds too obscure and fragile to me. Moreover, I don't think this is specific to Org: any mode that folds or hides portions of text might hit the same problem. So we could decide that this command needs to become smarter when the visual line includes invisible text. That is, improve the command without making any Org-specific changes anywhere. Patches to that effect are welcome. > 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. This could be handled by a suitable extension to end-of-visible-line. For example, introduce a new text property which end-of-visible-line would then handle the same as it currently handles invisible text.