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