From: Eli Zaretskii <eliz@gnu.org>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?
Date: Sun, 22 Dec 2019 20:38:41 +0200 [thread overview]
Message-ID: <83sglcxl1q.fsf@gnu.org> (raw)
In-Reply-To: <20191221214751.GB8692@ACM> (message from Alan Mackenzie on Sat, 21 Dec 2019 21:47:52 +0000)
> Date: Sat, 21 Dec 2019 21:47:52 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
>
> 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.
next prev parent reply other threads:[~2019-12-22 18:38 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-21 17:23 /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not? Alan Mackenzie
2019-12-21 18:11 ` Eli Zaretskii
2019-12-21 21:47 ` Alan Mackenzie
2019-12-22 18:38 ` Eli Zaretskii [this message]
2019-12-24 9:47 ` Alan Mackenzie
2019-12-24 12:51 ` Alan Mackenzie
2019-12-24 15:58 ` Eli Zaretskii
2019-12-24 15:47 ` Eli Zaretskii
2019-12-29 13:34 ` Alan Mackenzie
2019-12-29 16:23 ` Stefan Monnier
2020-01-03 8:45 ` Eli Zaretskii
2020-01-04 22:47 ` Alan Mackenzie
2020-01-05 18:17 ` Eli Zaretskii
2020-01-05 18:48 ` Alan Mackenzie
2020-01-21 20:34 ` Alan Mackenzie
2020-01-22 3:27 ` Eli Zaretskii
2020-01-22 20:05 ` Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83sglcxl1q.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.