From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Sun, 4 Dec 2016 12:20:33 +0000 Message-ID: <20161204122033.GA2791@acm.fritz.box> References: <83bmwuogfb.fsf@gnu.org> <878trydrbo.fsf@red-bean.com> <83a8cem1eq.fsf@gnu.org> <83zikdl7oo.fsf@gnu.org> <83y3zxkwms.fsf@gnu.org> <20161203143603.GA6921@acm.fritz.box> <83wpfhkpy2.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1480854098 17728 195.159.176.226 (4 Dec 2016 12:21:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Dec 2016 12:21:38 +0000 (UTC) User-Agent: Mutt/1.5.24 (2015-08-30) Cc: kfogel@red-bean.com, dancol@dancol.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 04 13:21:33 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDVnR-0004Ck-L1 for ged-emacs-devel@m.gmane.org; Sun, 04 Dec 2016 13:21:33 +0100 Original-Received: from localhost ([::1]:34133 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDVnV-0007wr-92 for ged-emacs-devel@m.gmane.org; Sun, 04 Dec 2016 07:21:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDVmv-0007wT-Dr for emacs-devel@gnu.org; Sun, 04 Dec 2016 07:21:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDVmq-0005Pc-OL for emacs-devel@gnu.org; Sun, 04 Dec 2016 07:21:01 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:15617 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cDVmq-0005Ox-FX for emacs-devel@gnu.org; Sun, 04 Dec 2016 07:20:56 -0500 Original-Received: (qmail 82323 invoked by uid 3782); 4 Dec 2016 12:20:54 -0000 Original-Received: from acm.muc.de (p548C7677.dip0.t-ipconnect.de [84.140.118.119]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 04 Dec 2016 13:20:53 +0100 Original-Received: (qmail 3883 invoked by uid 1000); 4 Dec 2016 12:20:33 -0000 Content-Disposition: inline In-Reply-To: <83wpfhkpy2.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.4 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:210015 Archived-At: Hello, Eli. On Sat, Dec 03, 2016 at 05:11:33PM +0200, Eli Zaretskii wrote: > > Date: Sat, 3 Dec 2016 14:36:04 +0000 > > From: Alan Mackenzie > > Cc: kfogel@red-bean.com, Daniel Colascione , > > emacs-devel@gnu.org > > 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 can't really estimate it accurately (or it would take far too much time to do so). It could be as high as 1 in 3. It could be as low as 1 in 10. > > (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. I've found that thread, and I misremembered it. The preceding discussion was not extensive. It was in the thread with Subject: "bug#22884: 25.0.92; C/l mode editing takes waaaayy too long" and essentially consisted of just three emails: (i) Alan -> Eli: Thu, 3 Mar 2016 23:18:23 +0000 (ii) Eli -> Alan: Fri, 04 Mar 2016 10:32:56 +0200 (iii) Alan -> Eli: Fri, 4 Mar 2016 09:37:07 +0000 . In (i), I proposed using text properties to cache the string/comment state of positions, and asked you whether that might overwhelm the text property mechanism. In (ii) you replied that it shouldn't. In (iii) I announced my intention to hack it, which I then did. I don't remember you reviewing the patch, or expressing any further views on it afterwards, so we agree on that. The discussion after I submitted my patch happened in the threads Subject: "Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text properties when calling `back_comment'." and Subject: "Permission requested to merge branch comment-cache into master.". This discussion was long and (to me) unexpectedly aggressive, and didn't concern itself with the correctness of the patch. It seemed intended to prevent the adoption of my patch by spreading FUD. If this was indeed the intention, it was entirely successful. > > (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. I've read through that debbugs bug archive. It was a long time ago. I remember feeling discouraged that my patch was not considered. I think I felt that my patch fixed the fundamental problem in xdisp.c, whereas the patch actually applied was more of a workaround. Or something like that. But I didn't push the point at the time. > > (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. OK. But the notion of acutally fixing the primitives so that they would each call b-c-f and a-c-f was strongly discouraged, if I remember correctly. > > 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. Perhaps it is that last point (that C functions are more likely to be critical to Emacs's working than lisp functions, and therefore the testing is more important) that is the thing. -- Alan Mackenzie (Nuremberg, Germany).