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: Bug #25608 and the comment-cache branch Date: Sat, 11 Feb 2017 23:25:11 +0000 Message-ID: <20170211232511.GA13712@acm> References: <20170202202418.GA2505@acm> <83lgtouxpf.fsf@gnu.org> <20170202215154.GB2505@acm> <83h94bvhzw.fsf@gnu.org> <20170205220045.GB2294@acm> <83d1es61li.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 1486855578 13901 195.159.176.226 (11 Feb 2017 23:26:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 11 Feb 2017 23:26:18 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 12 00:26:14 2017 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 1cch3T-00039H-4G for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2017 00:26:11 +0100 Original-Received: from localhost ([::1]:49947 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cch3X-0005cO-1u for ged-emacs-devel@m.gmane.org; Sat, 11 Feb 2017 18:26:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cch2y-0005cI-CY for emacs-devel@gnu.org; Sat, 11 Feb 2017 18:25:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cch2v-0001DE-6r for emacs-devel@gnu.org; Sat, 11 Feb 2017 18:25:40 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:57468 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cch2u-0001Cb-TS for emacs-devel@gnu.org; Sat, 11 Feb 2017 18:25:37 -0500 Original-Received: (qmail 89684 invoked by uid 3782); 11 Feb 2017 23:25:32 -0000 Original-Received: from acm.muc.de (p4FC460E3.dip0.t-ipconnect.de [79.196.96.227]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 12 Feb 2017 00:25:32 +0100 Original-Received: (qmail 14573 invoked by uid 1000); 11 Feb 2017 23:25:11 -0000 Content-Disposition: inline In-Reply-To: <83d1es61li.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:212251 Archived-At: Hello, Eli. Thanks for the reply. On Wed, Feb 08, 2017 at 19:20:41 +0200, Eli Zaretskii wrote: > > Date: Sun, 5 Feb 2017 22:00:45 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > But I need your acceptance of comment-cache to go any further. It has > > taken a lot of my time to develop, and I am still hopeful of merging it > > into master. If there is a sound technical reason why it should be > > abandoned, that is fair enough. If it is rejected without such a > > reason, I will need to reconsider my relationship with Emacs. I am > > currently working (or "working") on several ambitious changes in Emacs. > > One of them is restructuring the byte compiler so that error and warning > > messages get the correct line number (bug #22288, etc.). If there is > > the prospect of these being rejected without good reason, I am not > > willing to take the risk of wasting my time on them. I would restrict > > my participation in Emacs to CC Mode and simple changes in the non-C > > part of Emacs which can be done in at most a very few hours. > Alan, > I hear you, and I'm sorry that you feel such frustration over your > efforts whose results might not end up in the Emacs sources. Please > understand my position: I'm not an expert on the underlying issues, > neither syntax.c in general, nor syntax-ppss, and not the particular > application of these to CC Mode. So when two of our best experts on > these issues unanimously disagree with your proposal, I cannot dismiss > their opinions and approve the merge. I am something of an expert myself on syntax.c, having enhanced it to handle comments continued by escaped newlines, to handle a scan stopping in the middle of a two-character comment delimiter, having refactored important bits of it and fixed several bugs in it. > Their arguments are technical and sound, even though they are about > the general principles of your design and not about specific details > of your implementation. But that doesn't make their arguments invalid > or less sound. > So please don't perceive this as "rejection without sound technical > reasons". Yet an important bug remains unfixed. comment-cache would fix that bug. I would expect you to take this into account when weighing up the arguments for and against. I would expect you to take into account all the technical arguments both for and against, and to place less importance on who is arguing than the substance of their arguments. You say you are "not an expert" on the issues, yet I don't think this is strictly true. You know easily enough about syntax to understand the arguments about it. > As for your other work on changes in Emacs: I see no reasons to > believe their review or prospects of acceptance will be related to the > present issue in any way. They will be treated completely > independently of this one. As I say, I an unhappy about the way the comment-cache issue has been handled. I asked on three separate occasions to merge it into master. On the first two (2016-03 and 2016-12), I received no clear answer. This third time there is at last a "no", but the reason given is not technical but on others' personal authority: "when two of our best experts ... disagree" their opinion holds sway over mine, seemingly regardless of the strength of the technical points. Two against one, I suppose. > I can understand your fears of having those other changes rejected > because of some aspect of the design or the implementation. My fear is that speculative changes might well not be evaluated on technical grounds, as I feel comment-cache has not been. None of the posts opposing comment-cache have even acknowleged that it fixes a bug, and none of them have attempted to weigh comment-cache's alleged disadvantages against the fact of the bug fix. In the current situation I think that both Stefan and Dmitry have an emotional attachment to syntax-ppss despite its manifest flaws, and it is this which is behind their opposition to comment-cache, which they see as some sort of "competitor". (Here, I don't hide the fact that I strongly dislike syntax-ppss.) > I had my share of that when I worked on the bidi display engine. I > can tell what I did to lower the probability of such an outcome: when > I made major design decisions, I published them here and asked for > (and received) comments. May I suggest that you try that technique as > well? I announced my intention to cache the literal state in text properties before starting work on it, and even had a brief exchange with yourself about this. I think this was in the context of bug #22884 (Paul E.'s bug about slowness in config.h, which was quickly tracked down to an open paren in column 0 inside a comment). > Doing that will IME go a long way towards identifying the problematic > issues long before they are cast in written and debugged code, and > thus allow you to avoid unnecessary refactoring and grief. > Hoping to see many of your patches in Emacs in the years to come. > TIA -- Alan Mackenzie (Nuremberg, Germany).