From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id KG7pIAOk+WSUvgAAG6o9tA:P1 (envelope-from ) for ; Thu, 07 Sep 2023 12:20:51 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id KG7pIAOk+WSUvgAAG6o9tA (envelope-from ) for ; Thu, 07 Sep 2023 12:20:51 +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 125043E9D0 for ; Thu, 7 Sep 2023 12:20:51 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=lJNjmgth; 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=1694082051; 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=wk+dCVtdvorLfd5DfGTe+YAQBn567+qXNgnYuLvUg3Q=; b=jj1Q4Yq2ND4SA2l2+8Cyt5zsTpWPBKpdJmoDaXUvirmg8eSuHAiqmJA7zUMl8X3Sekgyfv VQz/9RxX13OE1eWToJqtN/50VmtECU4KTgfqwlnfsUxyLUDugy4KS97AFvf5znU8CSUytW uMWHcThfWDdDWT+1dvXZyYh9vR6TaXA1lioWPyspv2L14RjtThAzQVcpjn0C8kpzeM2nLs aJOCG10ZsRyM6L5QpBTD78ivPlEM9JJIF1ZyFl74ZMKJdtT+JY95qfhM/UPn+l1HE57DuW 8nN+blhqzHYEWuAqMctj7eVzbEZ9bRZrMEDnUXGU5nCmI2BLgbTWOlGY41B72A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gnu.org header.s=fencepost-gnu-org header.b=lJNjmgth; 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-Seal: i=1; s=key1; d=yhetil.org; t=1694082051; a=rsa-sha256; cv=none; b=FnvYdIQ9dsPfRr0Sn3OURw0oaMYdqfS5TIH4zyb5/T/pVfZeAl5blGBkvEw/HW2x1+VE9f A7/o3jbsIH2XZgwqBNmshBCKBa0QIdrOmvbdueU8ZcnSe4WopaBuy23mJzuNh8KdZ6u+KL pHA9XzyMKL70PRrHFD057UHICbbyIc/uqCuq0lEiejqg+iN8ldvUXQ/JzbuTR5+uEruBmt sOaHQB9v5vy4tzHzzNWRt3Whga/RfVpgomj2xCYBM3ioDYAqloMjeVczFtxg4fBX+rX9t0 h/O42Bg7Bx7i4d1LtM6Lkcfc7oLE7Aj6WMIVXLlbHNbJSqJoTRZd9GMjdA+f/w== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qeC7I-0000FE-Ja; Thu, 07 Sep 2023 06:20:05 -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 1qeC7G-0000C4-1V for emacs-orgmode@gnu.org; Thu, 07 Sep 2023 06:20:02 -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 1qeC7E-0007vR-IH; Thu, 07 Sep 2023 06:20:00 -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=wk+dCVtdvorLfd5DfGTe+YAQBn567+qXNgnYuLvUg3Q=; b=lJNjmgthrITF tTFV9GiqAmt9LXnfyATnHpN0bxTVaIe/2iZ5p+RDKNZ8dQ5fZbRuSiSmRSTwxt4zQBqXb0JfV+zZd QINRUho3Tn7lwyvXrmwoRJyBpo4NvXSwUjhST2WFuM0s1SrW0fRmE5+rYukWhTvO4hV6POHq2al6Z RdCcZ2oPh1ZatuHXB/W5k0IZrQ4R8SHnhqNcO8cmtDPD1E6Kp2fJE5z6hGQQ79NnfVt+wfMCMEBoa CgJTtz5Cx+tNd+qe5ckFrDowTkzyZAwu8YtpLxuzGnho/N2aJo2LIH0GF+0lIPvtGSMFW8g3882Ej hjJvtzv0Zffp7xgKuOBMZw==; Date: Thu, 07 Sep 2023 13:19:48 +0300 Message-Id: <83il8mz3nf.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko Cc: iota@whxvd.name, 65734@debbugs.gnu.org, emacs-orgmode@gnu.org In-Reply-To: <87pm2upajy.fsf@localhost> (message from Ihor Radchenko on Thu, 07 Sep 2023 10:00:49 +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> <83h6o84yz1.fsf@gnu.org> <87ledju2j7.fsf@localhost> <837cp3333w.fsf@gnu.org> <87pm2upajy.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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Queue-Id: 125043E9D0 X-Migadu-Scanner: mx1.migadu.com X-Migadu-Spam-Score: -7.97 X-Spam-Score: -7.97 X-TUID: dCmoFHJfOuM7 > From: Ihor Radchenko > Cc: iota@whxvd.name, 65734@debbugs.gnu.org, emacs-orgmode@gnu.org > Date: Thu, 07 Sep 2023 10:00:49 +0000 > > Eli Zaretskii writes: > > > Then perhaps just a special value for buffer-invisibility-spec, or > > some other simple variation of a property Org already uses? > > We may have a misunderstanding here. > In "* Heading text :tag1:tag2:", everything is visible yet Org needs to > protect ":tag1:tag2: from being killed by `kill-line', but not from > `kill-whole-line'. Moreover, the behaviour also depends on the point > position - if point is inside ":tag1:tag2:", we fall back to the default > behaviour. And the whole "special" behaviour can also be switched off by > flipping `org-special-ctrl-k'. > > Invisibility has nothing to do with this need. Isn't it true that invisibility is what causes the user expectations in this case to begin with? Then saying that "invisibility has nothing to do with this" is not really accurate, is it? > >> What about something like `end-of-visible-line-function'? > > > > That is also a possibility, but it will then affect kill-line > > _anywhere_ in the buffer, whereas a text property can have a more > > localized effect. Are you sure kill-line will need this customization > > on the whole buffer? > > Applying text property is not free - (1) we need to do it across the > whole buffer, which scales poorly; (2) we need to keep it updated as the > buffer changes, which scales even worse. In addition, adding more text > properties slow down redisplay, which Org already strains to its limits. I understand, but in my book correctness tramps performance, and I was trying to make the point that perhaps modifying the behavior of kill-line everywhere in Org buffers might be incorrect for some cases.