Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 24 Dec 2019 09:47:24 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> The point is not to call prepare_to_modify_buffer twice at the same
> position.

Why is that a problem?  Surely, something like that can happen in real
life, and any modification hook should be prepared to deal with that?

> > I think you should simply call signal_after_change after the call to
> > del_range_2 (telling the after-change hooks that actually nothing was
> > inserted or deleted).  Then you won't need the prepared_position
> > thingy.
> 
> After thinking it over a couple of days, I can't agree this is a good
> idea.  Calling before/after-change-functions for a non-change would be
> very unusual in Emacs - I don't know of anywhere where this is currently
> done - and would surely cause problems somewhere, and would certainly
> cause some inefficiency.  Also we would have to amend the Change Hooks
> page in the Elisp manual to warn of this possibility.

Again, I don't see why this could cause any trouble.  Inserting an
empty string is not an outlandish situation, and any modification hook
must be prepared to (trivially) deal with it.

IOW, jumping through hoops in order to avoid such calls is IMNSHO
unjustified.  It will definitely complicate code, and thus will run
higher risk of subtle bugs.  Why risk that?