emacs-devel
[Top][All Lists]
Advanced

[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: Alan Mackenzie
Subject: Re: /* FIXME: Call signal_after_change! */ in callproc.c. Well, why not?
Date: Sun, 5 Jan 2020 18:48:44 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

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).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]