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

[Alan Mackenzie]

Hello, Emacs.

I've just had a bug report on bug-cc-mode from "Sun, Wei"
<address@hidden> (Subject: bug#38691: CC Mode 5.34 (C++//lhw);
`Invalid search bound` when undo).

Essentially, this bug is reproduced by inserting a single line comment
(complete with CR) into an otherwise empty C++ Mode buffer:

    // 2019-12-20 17:57

, then doing
  C-x C-p (mark-page),
  C-u M-| <CR> sort <CR> (shell-command-on-region), then
  C-_ (undo).

This throws an error.

The cause of the error is that the C function call_process in
src/callproc.c is calling before-change-functions, but fails to call
after-change-functions.  This is at callproc.c ~L790, where there is the
helpful comment:

    /* FIXME: Call signal_after_change!  */

(thanks, Stefan!).

Well, I've tried adding this call to signal_after_change thusly:



diff --git a/src/callproc.c b/src/callproc.c
index b51594c2d5..6d74b34068 100644
--- a/src/callproc.c
+++ b/src/callproc.c
@@ -785,9 +785,11 @@ call_process (ptrdiff_t nargs, Lisp_Object *args, int 
filefd,
            {                   /* We have to decode the input.  */
              Lisp_Object curbuf;
              ptrdiff_t count1 = SPECPDL_INDEX ();
+              ptrdiff_t beg;
 
              XSETBUFFER (curbuf, current_buffer);
              /* FIXME: Call signal_after_change!  */
+              beg = PT;
              prepare_to_modify_buffer (PT, PT, NULL);
              /* We cannot allow after-change-functions be run
                 during decoding, because that might modify the
@@ -798,6 +800,7 @@ call_process (ptrdiff_t nargs, Lisp_Object *args, int 
filefd,
              decode_coding_c_string (&process_coding,
                                      (unsigned char *) buf, nread, curbuf);
              unbind_to (count1, Qnil);
+              signal_after_change (beg, 0, PT - beg);
              if (display_on_the_fly
                  && CODING_REQUIRE_DETECTION (&saved_coding)
                  && ! CODING_REQUIRE_DETECTION (&process_coding))


, and this appears to solve the OP's problem.

However, a few lines further on, there's a del_range_2 call inside a condition
I don't understand (though might, with a great deal of study).  I suspect that
the call to signal_after_change ought to take this del_range_2 into account,
possibly coming after it.

Would somebody who's familiar with this bit of callproc.c please help me out
here, and explain what this call to del_range_2 is doing, and whether there's
anything basically wrong with my simple-minded addition of
signal_after_change.

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).