From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs 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: Mon, 08 Jan 2024 10:33:40 -0500 Message-ID: References: <87il8pao4l.fsf@whxvd.name> <87tts8vrpb.fsf@localhost> <83cyyw4of7.fsf@gnu.org> <875y4ovct9.fsf@localhost> <875y04yq9s.fsf@localhost> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26267"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-orgmode@gnu.org, Eli Zaretskii , 65734@debbugs.gnu.org, Max Nikulin , iota@whxvd.name To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 08 16:35:18 2024 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 1rMreo-0006Tf-0S for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Jan 2024 16:35:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rMree-0004i7-55; Mon, 08 Jan 2024 10:35:09 -0500 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 1rMreS-0004gr-LF for bug-gnu-emacs@gnu.org; Mon, 08 Jan 2024 10:34:59 -0500 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 1rMreS-0004YY-Cy for bug-gnu-emacs@gnu.org; Mon, 08 Jan 2024 10:34:56 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rMreY-0005tT-84 for bug-gnu-emacs@gnu.org; Mon, 08 Jan 2024 10:35:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Jan 2024 15:35: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.170472804422584 (code B ref 65734); Mon, 08 Jan 2024 15:35:02 +0000 Original-Received: (at 65734) by debbugs.gnu.org; 8 Jan 2024 15:34:04 +0000 Original-Received: from localhost ([127.0.0.1]:37311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMrdb-0005sB-Ks for submit@debbugs.gnu.org; Mon, 08 Jan 2024 10:34:03 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62104) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rMrdW-0005rb-QZ for 65734@debbugs.gnu.org; Mon, 08 Jan 2024 10:34:01 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 325C6100115; Mon, 8 Jan 2024 10:33:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704728021; bh=GjHtmJu/OrYIOYz8sKCRsrVTvgSIo+ofw1n4boZ5NYw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bKW619XAmILr6YjWAwTeX6WxPvgJ14ujJ9ftoaUzhtwfghLCT89SG8UHDflW3LYNb Rhai5UAPxTKz2yMmp5c4LaBITSsi+iKX9q9hHSlsFHhoEBWq+KQGuEprjg8uIKwxrW cX2vD+gaWqgBfONrnTrkcm38GAOfAB1IMzpLptmJCyWyAgV3qx+CTXItejc8swUqzY hh2kVw21qWpoBp8nHLUi7v5euNEY+yla5BzbpusvPJy80+OfVXgzMJu9LxmBxJSmOJ r72oYFRFzmUwTYef0aow0Uv1V54CK39lArAveNTZ7ri8aHJLbJmnLDlBGaPWagLHB3 AP8781oyGlCoQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B729310004C; Mon, 8 Jan 2024 10:33:41 -0500 (EST) Original-Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7E2F4120BE4; Mon, 8 Jan 2024 10:33:41 -0500 (EST) In-Reply-To: <875y04yq9s.fsf@localhost> (Ihor Radchenko's message of "Mon, 08 Jan 2024 12:15:59 +0000") 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:277565 Archived-At: >> As a rule of thumb, I think modification hooks should be treated a bit >> like POSIX signal handlers: just record the event somewhere but don't do >> any substantial work in there. > Yet, it is sometimes necessary to modify text right inside the > modification hooks. Otherwise, it is very hard (and sometimes > impossible) to keep track of the original text region when multiple > modifications happen there one by one. It's always "possible", but yes there can be undesirable effects: usually as you delay the updates you're forced to reduce the granularity of the recorded changes, so in you may end up treating a series of small changes as one big-ass change for which your updates may not be able to do as good a job. E.g. in `diff-mode` we try to allow editing the patch, and dynamically update the hunk headers accordingly. This works well for an edit within a single hunk but doing it for larger edits is somewhere between hard and undesirable so we don't do it. If a command changes just two lines but in two different hunks, our code treats it a a single change that spans two hunks and thus refrains from updating the hunk headers, as if the command had actually deleted and then reinserted all the text between those two lines. That's why I said "rule of thumb": there can be tradeoffs. In practice 99% of Emacs commands modify only a single contiguous chunk of text, so the tradeoff comes into play fairly rarely. Stefan