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

[Dmitry Gutov <dgutov@yandex.ru>]

Hi Alan,

On 03/17/2016 08:47 PM, Alan Mackenzie wrote:
> 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.

Sorry about that? Carrying around too much context makes me 
uncomfortable when writing, or reading, emails. If anything, the lack of 
context was not a cause for misunderstanding on my side.

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

Honestly, I'm not sure which references would have helped, and how; CC 
Mode was last mentioned directly (not in a quote) in the grand{7}parent 
of this message.

> 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,

I'm sorry for misunderstanding, and hence misstating the state of 
affairs with comment-cache. But if you reread your previous email (or 
two), I believe you can agree that the fault is not entirely mine.

To be continued privately.

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

I have now posted the big and scary patch to the bug thread, to address 
this complicated issue.

>> The narrowing thing is relatively minor, ....
>
> I think your reasoning is that because you personally don't use
> narrowing, it is of no importance.

No, I'm saying that because the nature of the problem is clear, and the 
ways we can fix it don't affect the usage of syntax-ppss in the proposed 
patch.

> I also disagree with you that "sort of works" is good enough.

Did I claim that?

> Maybe it
> comes from my background in embedded systems, where the cost of failure
> is inordinately high, hence rigorous testing is the norm.

My background is in high level programming, where there's usually a lot 
of concepts in a system. Not entirely unlike what we have in Emacs.

The idea of someone introducing a parallel, subtly incompatible, 
implementation of an existing widely used facility, without studying it 
carefully and making sure to unify the duplicated parts (or at least 
making an honest effort toward that), is nothing to celebrate either.

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

This is volunteer work: it's not strict enough because nobody has 
invested the necessary work. Even so, we don't get to ignore or remove 
syntax-ppss just because it doesn't meet your standards, without 
providing an adequate replacement.

> [ .... ]
>
>> 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?

That's a good sentiment.

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

The stuff about not duplicating things is a matter of economy of effort, 
too.

Producing adequate test cases for patches, that justify the choices 
made, is a matter of economy of effort too, but in a different respect.

Trying to fix an issue one doesn't have a good understanding of, can 
lead to wasted effort as well. Both in the process and down the line, if 
the vaguely beneficial improvement gets merged.