Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?

[Alan Mackenzie]

Hello, Eli.

Ping?

Could we move forward with this, please?

On Sun, Jan 05, 2020 at 18:48:44 +0000, Alan Mackenzie wrote:
> Hello, Eli.

> On Sun, Jan 05, 2020 at 20:17:44 +0200, Eli Zaretskii wrote:
> > > Date: Sat, 4 Jan 2020 22:47:30 +0000
> > > Cc: address@hidden
> > > From: Alan Mackenzie <address@hidden>

> > > OK.  I have to say here, I really don't believe such an extensive
> > > commentary is needed here.  The code is there, and anybody
> > > generally familiar with our C code would understand it without a
> > > great deal of difficulty, even the mechanism which prevents a
> > > spurious second call to prepare_to_modify_buffer.  Surely?

> > If you think this is a waste of effort, you can leave the commentary
> > to me.

> It was more that that amount of commentary, 21 lines, could well get in
> the way, rather than being a help.

> > >              For each iteration of the enclosing while (1) loop which
> > >              yields data (i.e. nread > 0), before- and
> > >              after-change-functions are each invoked exactly once.
> > >              This is done directly from the current function only, by
> > >              calling prepare_to_modify_buffer and signal_after_change.
> > >              It is never done by directing another function such as
> > >              insert_1_both to call them.

> > The last sentence above is inaccurate, since insert_1_both does call
> > prepare_to_modify_buffer.

> insert_1_both _can_ call prepare_to_modify_buffer, but only if it's
> directed to do so by setting its PREPARE parameter to true.  Here it is
> set to false, to make it easier to keep control of the various
> prepare_to_modify_buffer's and signal_after_change's.  How about
> changing the last sentence to:

>     It is not done here by directing another function such as
>     insert_1_both to call them.

> ?

> > Thanks.

> -- 
> Alan Mackenzie (Nuremberg, Germany).

-- 
Alan Mackenzie (Nuremberg, Germany).