From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not? Date: Sat, 21 Dec 2019 17:23:24 +0000 Message-ID: <20191221172324.GA8692@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="1807"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 21 18:24:35 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iiiUV-0000MW-79 for ged-emacs-devel@m.gmane.org; Sat, 21 Dec 2019 18:24:35 +0100 Original-Received: from localhost ([::1]:41150 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iiiUT-00015X-Fs for ged-emacs-devel@m.gmane.org; Sat, 21 Dec 2019 12:24:33 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56135) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iiiTW-0000dO-57 for emacs-devel@gnu.org; Sat, 21 Dec 2019 12:23:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iiiTU-0007zO-Gh for emacs-devel@gnu.org; Sat, 21 Dec 2019 12:23:33 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:32491 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1iiiTU-0007sf-5b for emacs-devel@gnu.org; Sat, 21 Dec 2019 12:23:32 -0500 Original-Received: (qmail 23916 invoked by uid 3782); 21 Dec 2019 17:23:26 -0000 Original-Received: from acm.muc.de (p2E5D57F0.dip0.t-ipconnect.de [46.93.87.240]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 21 Dec 2019 18:23:25 +0100 Original-Received: (qmail 8832 invoked by uid 1000); 21 Dec 2019 17:23:24 -0000 Content-Disposition: inline X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243539 Archived-At: Hello, Emacs. I've just had a bug report on bug-cc-mode from "Sun, Wei" (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-| sort (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).