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/)]

[Stefan Monnier]

>> 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