Re: Bug #25608 and the comment-cache branch

[Alan Mackenzie <acm@muc.de>]

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 <acm@muc.de>

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