Re: Preview: portable dumper

[Eli Zaretskii]

> Date: Sat, 3 Dec 2016 14:36:04 +0000
> From: Alan Mackenzie <address@hidden>
> Cc: address@hidden, Daniel Colascione <address@hidden>,
>       address@hidden
> 
> However, it feels that an unusually high proportion of C level changes I
> have hacked or proposed have been rejected.  ("Unusual" when compared to
> lisp level changes.)

Can you estimate that proportion?  You cited 3 examples, and then said
that "a lot of changes have been accepted".  3 out of many is not a
high proportion.

> (i) Changing the method of syntax.c scanning backwards over comments.  My
> changes found their way into branch comment-cache in 2016-03.  Despite
> this change having been extensively discussed in emacs-devel, and sort of
> "approved", the final patch was never considered on its merits.  The
> ostensible reason was that it used a cache which wasn't the syntax-ppss
> cache.

I don't think I participated in that discussion or reviewed that
patch, so I cannot say anything about that.

> (ii) Around 2015-11-17, I proposed a patch to fix bug #21869 and bug
> #21333, with top line of the commit message being "Invoke
> window-size-change-functions after changing echo area height.".  The
> problem here was that window-size-change-functions was sometimes being
> called twice.  You rejected my patch because you were "not keen" on
> changing the order of calls in the display engine because we "didn't
> fully understand what was going on".  Again, I don't think this proposed
> patch was really considered on its merits.

Please see

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21869#23

It indicates that we already had a patch for those problems, which was
already tested quite a lot by that time.  I think it's only natural to
prefer a well tested and discussed patch to a new one trying to fix
the same problem.  Reading this message further down:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21869#37

I see that you agreed that the problem was fixed by the patch we had,
which allowed me to close the bug.

> (iii) Earlier this year, we were having problems because some primitives
> were not calling before-change-functions and after-change-functions the
> way we might wish.  My offer to analyse the code and amend it so that all
> primitives would call b-c-f and a-c-f predictably was declined, the
> proviso being (if I remember correctly) "unless somebody writes a solid
> suite of unit tests".  At the time of this rejection, I'd already
> invested some time on the analysis.

That's not exactly my recollection.  The analysis was not rejected, I
simply already did it when you proposed that, so it wasn't necessary.

> In short, I feel discouraged from working at the C level because of the
> above.

Please don't be discouraged.  There's no policy of preventing changes
on the C level.  However, for some changes which affect important
functions, I think it's prudent to require a reasonable coverage by
tests, so that we know we didn't break anything.