[Top][All Lists]

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

[AUCTeX-devel] Re: Changes in font locking

From: Stephen J. Turnbull
Subject: [AUCTeX-devel] Re: Changes in font locking
Date: Thu, 15 Mar 2007 16:36:29 +0900

David Kastrup writes:

 > This problem has been reported in the past by both Gnus and AUCTeX
 > developers in a civil manner, and ignored.

We have taken notice; we simply haven't fixed it, due to other claims
on developer time.  It's been *tabled*, with no date set for
continuance.  That is very different from "ignoring".  To contrast
"ignoring" with "report in civil manner" is to make an implicit claim
that we "owe" you something, simply because you report it.  Sorry;
we're *all volunteers*, and quite time-constrained.  We can't even
muster a Google Summer of Code mentor.

 > Talk about double standards.

Not at all.  I don't blame you for *not looking*, I object to you
*attacking me* for not looking, when you make the same kind of
decision based on your own constraints.  All I intended was to point
out that it would have been equally easy for you to look at Emacs
history, because it happens that in this case that was the relevant
place to look.

 > Well, if you and other XEmacs developers have better things to do
 > than fixing bugs in XEmacs,

Nice own-troll!  No, we don't have better things to do than fix bugs;
we just have better things to do than fix *this* bug.  YHBT HAND.

Really, if XEmacs were so wonderful that the obvious bug to fix is the
with-syntax-table bug, you would be out collecting assignments for it
so that you could use it in good conscience.

 > why should this work be done by people not even using XEmacs?

Who am I to judge others' reasons?  I only judge my own: I have no
personal reason to care about this bug.  It's not a quality issue.  If
I fixed currently known bugs 24 hours a day, I could probably go 10
years without needing to look at with-syntax-table.

People who *do* care *can* make the effort, and in this case I decided
I would leave it to them.  Who knows why volunteers do what they do?
If they want to do it, they will.  Whether they use XEmacs or not
makes no matter.

It's actually very sad, because I should have a personal reason.  I
respect and *like* you, David, though I rarely have the opportunity to
express that.  Your bug reports *should* be such a chance.  Because I
find your reporting style offensive, they're not, and realistically,
it's better for XEmacs if I table them -- if taking offense is a bug
in me, it's better for XEmacs that I don't fix it.  :-(  There are
lots of people who can fix the XEmacs bugs just as well as I can.
There are many other things that I should do *first*.

 > > Time constraint and bug triage is just an unfortunate reality in an
 > > open source project staffed by a declining number of volunteers.

 > You don't seem too concerned about that decline.  At least I can't see
 > much to encourage otherwise.

What do you think my consistent recommendation that you declare that
"XEmacs is not supported" is based on?  A hate for XEmacs?  Of course
I'm concerned.  But I refuse to adopt your approach of berating the
people who sometimes do contribute when they don't give my requests
priority over their own plans.

I wish you'd stop attributing motivation to me.  And I wish just as
much you'd stop assuming I attribute motivation to you.  It's against
my religion.

 > I made no claims about the history of this code: that was the
 > reason I asked for an XEmacs developer to use vc-annotate or its
 > equivalent for looking for it.

I make no claim that you made claims about the history of XEmacs
code; at least on auctex-devel, I'm sure that the majority would agree
with my assessment that you personally are unlikely to make them, it's
not your style.

My claim is that you denied that the copy-syntax-table call was in
Emacs 21, which is true.  <address@hidden>  You can say
"the word I used was 'doubt'", but the important thing is that's
enough to *strongly* discourage me from making the effort.  I don't
know if Ralf "felt" the same; I'm glad he went ahead and did it.

 > I don't remember doing any _claims_ warranting this kind of
 > chastisement.

"Chastisement" it is not; I don't judge you for making the claims.  I
simply need to point them out, because they're relevant to my acts.

I respect your judgment and knowledge of Emacs internals, and if you
say it's not there, even with some level of doubt, I'm not going to
waste time looking.

But the Emacs (no "X"!) history was the crucial datum!

Note, this is not *blame*, I simply point out that your comments
*could* have led to continued impasse.  You clearly didn't intend to
look, I was discouraged from looking.  It's due to raw good fortune
(and of course, Ralf's good will!) that somebody did look, and the
whole thing could be resolved with the amount of effort I'm willing to

You could say "Steve, you put far more effort into this flame fest
than it would have taken to do the research."  And that would be
correct, but very shortsighted.  To the extent that I accept
responsibility for XEmacs development, the *last* thing *I* should be
doing is fixing bugs.

IMO, right now the right answer for XEmacs 21.5 for bugs of this level
of importance is "WONTFIX".  We are *not* in prerelease mode.  We have
big problems that should be fixed before thinking about fixing this
kind of bug.  We can hope that they'll get fix en passant to some sync
or refactoring, but to put in core developer effort on fixing minor
bugs is too expensive to encourage.  Rather, I reluctantly tell 3rd
party library developers to stop breaking their heads on XEmacs bugs.
You know that very well; I probably tell you that about once every six

Other core developers probably feel differently (Aidan Kehoe, for one
likely candidate), but their own time constraints evidently prevent
them from "doing" much about it.  I take that as confirmation of my

Thus this thread of hot-headed apologia.

reply via email to

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