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 OJirC6TT+WRyGQAAG6o9tA:P1 (envelope-from ) for ; Thu, 07 Sep 2023 15:44:04 +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 OJirC6TT+WRyGQAAG6o9tA (envelope-from ) for ; Thu, 07 Sep 2023 15:44:04 +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 B703B63178 for ; Thu, 7 Sep 2023 15:44:02 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=cgumHZok; 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=1694094244; 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=viRvU6O//haDDURKpxhEZFwYTbtuVlje9CbL28BFirY=; b=e774b1raOUADSElbCtR1iUZn06Y1XOUE+d1Zuz3MwE7QFA20lA+1D6+XG8BWhIeztFKa0N OFJfnUZ6PYWQJfJRgq7F3KL9YJqrkvAzKtCql1kGRNNOLtmcmTdOnEwR5z0JPPqQ3NWAyn XA+XPxOdIZzolzrQo1gI4KiDMX1yE4go229yoNeX5TOba5jwxzXUYMiaxlNY7bL/8hzadn FKHpj2jp5MQBePv8vdRq2v30p+/i4e4o8rt0IjW0RRQvOVxGynxQw+XHcBc4NmZhmDcMdh meyTMorodvThnuclCnD160mlZvb9xZMUEiln4F2lj7QxUM2zXd09XEI/W8OzWA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=cgumHZok; 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-Seal: i=1; s=key1; d=yhetil.org; t=1694094244; a=rsa-sha256; cv=none; b=aajFe/yFGfm0sMcvelU2SXyY46/gQJpCae2pEA0Q7NMpzudubMfQuu9kiMSEzMel3GlbAo Pc2oYnoQ5dpOkrNvR0GTeR8127FvlUE59wxT33907OnNwn4MBUfbLY67JSS90teGeKhzFp UWSaxwzMQwVptG0redNaLq3QqWgJbvhFqNeQ/8iCesiyArfJn+I+SvShTWxCQLvy8aVv0D JKjZiql8yiBVmMBUCGuluHaU9ekJ4JNJjBES5XsyMjjp7WDlZ9l1gRz8Xf6P7HUjEulLAY UONQjzQIbVWw6fbbgpdxPBi3/NuRtnq7icpW/s1+2oYAfovWAzEmxVbK0STRVg== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qeFHw-00061y-Oi; Thu, 07 Sep 2023 09:43:16 -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 1qeFHu-0005yR-DU for emacs-orgmode@gnu.org; Thu, 07 Sep 2023 09:43:14 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qeFHq-0000DJ-1g for emacs-orgmode@gnu.org; Thu, 07 Sep 2023 09:43:12 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 1CC62240104 for ; Thu, 7 Sep 2023 15:43:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1694094187; bh=nLcyAH+MhlSPMDErdSkmEFNznBNe1Jdfd9zb77UFkPE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=cgumHZokZwa1VqOG3cpGupJqfEkjoceloPq/7aDXNtK6XIomfO5R9yuPnKdHb+grh IeXUO0BTFNcXRxYQqLo23Zy+2whx8EWqbzajFsmP9I9oRxTITLetqrachQkFK61TOH nExwn7BPZlCFIPlkgKByucDEDXWXjMrXZHwwi1xpoCFb2scyjgntZF7p9oXEWgJn6c tmttrWFzD7ZEJ8E0jUXfcdIqgE5fhkI8xE6gnTB+Ld9qIUv/5v3sd+t2quiUYREKRp 80o0XtF654JYrzWEfsCh1UdgGAAPR9fxvjZVlo3qdrwK2H6GT/DEXMiWLfsG2Aqqo+ Td7qrg0c919cw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RhL6L3TQbz9rxG; Thu, 7 Sep 2023 15:43:06 +0200 (CEST) From: Ihor Radchenko To: Eli Zaretskii Cc: iota@whxvd.name, 65734@debbugs.gnu.org, emacs-orgmode@gnu.org 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/)] In-Reply-To: <83il8mz3nf.fsf@gnu.org> References: <87il8pao4l.fsf@whxvd.name> <87tts8vrpb.fsf@localhost> <83h6o84yz1.fsf@gnu.org> <87ledju2j7.fsf@localhost> <837cp3333w.fsf@gnu.org> <87pm2upajy.fsf@localhost> <83il8mz3nf.fsf@gnu.org> Date: Thu, 07 Sep 2023 13:43:57 +0000 Message-ID: <878r9inlnm.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Queue-Id: B703B63178 X-Migadu-Scanner: mx1.migadu.com X-Migadu-Spam-Score: -6.44 X-Spam-Score: -6.44 X-TUID: QdE72RPsK17d Eli Zaretskii writes: >> 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? There are two things I raised in the previous messages: 1. The specific bug reported, related to invisibility changes in after-change-functions 2. A request to extend `kill-whole-line' and `kill-line' to cater Org needs: - for invisible text in folded headings - for visible text, when `kill-line' is called on a heading In this branch of the discussion, I am describing a request to deal with visible text. Hope I made things more clear now. >> >> 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. I think that `end-of-visible-line-function' might be more appropriate - it does not reduce correctness (we can simply fall back to the default behaviour when needed) and less problematic performance-wise, as I described. Or maybe some other idea. But not text properties - they are problematic performance-wise. In addition, `org-kill-line' is sensitive to point position (do different things at bol, before ":tag:...", and inside it). I am not sure how to make things depend on point position with text properties only. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at