Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text properties when calling `back_comment'.

[Alan Mackenzie <acm@muc.de>]

Hello, Dmitry.

First of all, I am most unhappy to read your post to which I will reply
in part.  You have trimmed so much away that the context has been totally
lost.  You have removed all mention of "syntax-ppss", leaving just lots
of "it"s.  You have removed references to CC Mode which would have
allowed other parts of your post to make sense.  This makes both of us
look like idiots arguing over trivialities.  

> And yet it [ the comment-cache branch ] doesn't solve 22884? How odd.

You have the audacity to state the falsehood that the comment-cache
branch doesn't fix bug #22884.  OF COURSE that code fixes bug #22884, and
you only needed to try it out to verify that.  Or you could have asked me
directly instead of formulating vague round-about questions which I was
foolish enough to answer directly.  Do you honestly think I'd commit a
patch for a bug which knowingly didn't fix that bug?

All I can say is that if your aim were to undermine me and discredit me
in place of honestly countering my arguments, your last post is a very
good example of how you could go about doing it.  I believe, and hope,
that it was not deliberate, and I'm asking you to be careful that you do
not write anything of that kind again to me.

OK, some details.

On Thu, Mar 17, 2016 at 02:47:10AM +0200, Dmitry Gutov wrote:
> On 03/14/2016 11:20 PM, Alan Mackenzie wrote:

[ Here "it" is syntax-ppss. ]

> > I meant, its deficiencies need fixing, and it's not clear at this stage
> > how that's to be done.  I've said elsewhere what I expect to happen:
> > that it will be superseded by a different function with the same name.

> And I've replied to it already. The "deficiencies" aren't fixed yet 
> because they haven't bothered anyone enough yet.

They bother me considerably, and they bother John, too.

> The narrowing thing is relatively minor, ....

I think your reasoning is that because you personally don't use
narrowing, it is of no importance.  I use it a lot, and one other person
has said he uses it a lot, too.  Narrowing is part of Emacs, just as much
as major modes or font locking, and "all" functionality must work with
it.

I also disagree with you that "sort of works" is good enough.  Maybe it
comes from my background in embedded systems, where the cost of failure
is inordinately high, hence rigorous testing is the norm.  The idea of a
function with undefined functionality (such as syntax-ppss) going into a
release because "nobody's complained about it" would inspire contempt and
disbelief in any of my colleagues.  Maybe that's just me.  Maybe "sort of
works" is good enough for Emacs.  I don't believe it is.  Bald tyres on a
car "sort of work" - until they don't.

> .... compared e.g. to bug#23019 you've filed recently.  Fixing that one
> would at least change the "internal data" of parse-partial-sexp.

I have a fix for it which I have not yet committed.

[ .... ]

> I mean, anticipating unknown problems sounds nice, but it's hardly the 
> most important thing, given we have plenty of known ones.

It's a matter of economy of effort.  When I come to fix a problem, I
always ask myself what was the misunderstanding or misconception or even
confusion which gave rise to it in the first place.  Where else could the
same misunderstanding lead to further problems?  If a fix, as well as
fixing the immediate bug, can also prevent further similar failures (not
necessarily identified) at the same time, it is a more economical use of
effort than just making a quick fix.  Remember, Emacs is ~30 years old,
and might well be in use for another 30 years.  That's an awful lot of
opportunity for hidden bugs to reveal themselves.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).