GNU bug report logs -
#65734
29.1.50; kill-whole-line and visibility of Org subtrees
Previous Next
Reported by: Sebastian Miele <iota <at> whxvd.name>
Date: Mon, 4 Sep 2023 14:49:02 UTC
Severity: normal
Found in version 29.1.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #107 received at 65734 <at> debbugs.gnu.org (full text, mbox):
>> 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
This bug report was last modified 329 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.