[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why no
From: |
Eli Zaretskii |
Subject: |
Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not? |
Date: |
Sun, 22 Dec 2019 20:38:41 +0200 |
> Date: Sat, 21 Dec 2019 21:47:52 +0000
> Cc: address@hidden
> From: Alan Mackenzie <address@hidden>
>
> 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.
- /* 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/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 <=
- 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