[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
/* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?
From: |
Alan Mackenzie |
Subject: |
/* FIXME: Call signal_after_change! */ in callproc.c. Well, why not? |
Date: |
Sat, 21 Dec 2019 17:23:24 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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).
- /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?,
Alan Mackenzie <=
- Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?, Eli Zaretskii, 2019/12/21
- Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?, Alan Mackenzie, 2019/12/21
- Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?, Eli Zaretskii, 2019/12/22
- Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?, Alan Mackenzie, 2019/12/24
- Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?, Alan Mackenzie, 2019/12/24
- Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?, Eli Zaretskii, 2019/12/24
- Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?, Eli Zaretskii, 2019/12/24
- Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?, Alan Mackenzie, 2019/12/29
- Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?, Stefan Monnier, 2019/12/29