From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not? Date: Sun, 22 Dec 2019 20:38:41 +0200 Message-ID: <83sglcxl1q.fsf@gnu.org> References: <20191221172324.GA8692@ACM> <83k16pzgzu.fsf@gnu.org> <20191221214751.GB8692@ACM> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="209423"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 22 19:39:33 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 1ij68b-000sKe-8s for ged-emacs-devel@m.gmane.org; Sun, 22 Dec 2019 19:39:33 +0100 Original-Received: from localhost ([::1]:49944 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ij68Z-0007nx-Mz for ged-emacs-devel@m.gmane.org; Sun, 22 Dec 2019 13:39:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35939) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ij688-0007Os-Or for emacs-devel@gnu.org; Sun, 22 Dec 2019 13:39:05 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46570) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ij688-0001Gc-2z; Sun, 22 Dec 2019 13:39:04 -0500 Original-Received: from [176.228.60.248] (port=3415 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ij687-0001y8-6x; Sun, 22 Dec 2019 13:39:03 -0500 In-reply-to: <20191221214751.GB8692@ACM> (message from Alan Mackenzie on Sat, 21 Dec 2019 21:47:52 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:243564 Archived-At: > Date: Sat, 21 Dec 2019 21:47:52 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > else if (NILP (BVAR (current_buffer, enable_multibyte_characters)) > && ! CODING_MAY_REQUIRE_DECODING (&process_coding)) > - insert_1_both (buf, nread, nread, 0, 1, 0); > + { > + beg = PT; > + insert_1_both (buf, nread, nread, 0, prepared_position < PT, 0); > + if (prepared_position < PT) > + prepared_position = PT; > + signal_after_change (beg, 0, PT - beg); ^^^^^^^^ 'PT - beg' is just 'nread' in this case, since we are inserting 'nread' characters. Right? And I don't think you need the prepared_position stuff here, since PT doesn't move in signal_after_change. > @@ -788,7 +796,11 @@ call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd, > > XSETBUFFER (curbuf, current_buffer); > /* FIXME: Call signal_after_change! */ > - prepare_to_modify_buffer (PT, PT, NULL); > + if (prepared_position < PT) > + { > + prepare_to_modify_buffer (PT, PT, NULL); > + prepared_position = PT; > + } > /* We cannot allow after-change-functions be run > during decoding, because that might modify the > buffer, while we rely on process_coding.produced to > @@ -822,6 +834,7 @@ call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd, > continue; > } > > + signal_after_change (PT, 0, process_coding.produced_char); > TEMP_SET_PT_BOTH (PT + process_coding.produced_char, > PT_BYTE + process_coding.produced); > carryover = process_coding.carryover_bytes; This really ugly, IMO. And the code logic is very hard to follow and verify its correctness, given the various use cases. 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. Thanks.