[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text

From: Dmitry Gutov
Subject: Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text properties when calling `back_comment'.
Date: Fri, 18 Mar 2016 03:24:35 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]