[TxMt] Re: C Library bundle MONSTER
William D. Neumann
wneumann at cs.unm.edu
Thu Dec 7 16:06:01 UTC 2006
On Wed, 6 Dec 2006, Kevin Ballard wrote:
> Man pages already exist to document this stuff. Having more documentation of
> the same stuff isn't any better.
It's documentation available quickly and easily inbthe same app that the
person is doing the coding in with no exrtaneous clutter. That's better
in my book.
> There's been discussion all day on the IRC channel about your bundle. It's
> not just Jacob that doesn't like this.
A) It's not my bundle. You may have noticed that "stephen" <> "william".
B) What percentage of the TextMate users are on the irc channel? I've
never gone on it and I see no reason to. There had been (prior to your
email) no other complaints about this bundle on either of the mailing
lists and now we're up to what... three? Yowza! Burn it to the ground.
>> "It doesn't work as well as it could" <> "compelling reason to delete". I
>> think most folk here would agree that the current syntax definition system
>> isn't working as well as it could. Should we just go ahead and scrap all
>> bundles that contain a syntax definition?
>
> That's a ridiculous exaggeration.
How is it ridiculous? Oh! I know! It's ridiculous in the same sense as
Jacob's original assertion... Imagine that... someone using exaggeration
to highlight exaggeration.
> It bothers the soul of this TextMate user as well. There's a big difference
> between saying "I don't use that" and saying "the mere fact that it exists
> bothers me".
Not much.
But hey, languages like C, Perl, and Python offend my sensibilities and
preferences -- and all the GTD stuff, it bugs me to the core. But somehow
I've managed to refrain from calling for the removal of those bundles.
Perhaps I should just give a day's warning and then delete them?
> If you want an uncommon but reasonable example of how your bundle might cause
> problems, think of user Joe Shmoe who has a repository checkout and is on
> dialup most of the day. Sure, the checkout itself is large, but he got it by
> letting svn work overnight (or perhaps he was at his friend's house with
> DSL). But he updates his checkout regularly over dialup, since the vast
> majority of updates are small in size, and doing it regularly means each
> individual checkout doesn't take long. Now he tries to update after your
> commit, and, oops, that's a few hours wasted while svn updates. And he
> doesn't want to cancel it because that would just mean he has to do it later.
Of course, his life would have been made much easier if the bundle
distribution system were set up differently in the first place. A quick
look at my filter bundles list shows 97 bundles that I have turned off,
and 40 turned on. And those 40 are essentially bundles that I may at some
point in the next year have a greater than 1% chance to actually use. If
I wanted to limit it to bundles that I have a 5% chance of using in the
next week, I could pare it down to 15. If I bump that up to 50%, then
it's down to 5 (probably 4) -- and I suspect other people have similar
useage patterns. Yet here we are, having to manage this diverse suite of
bundles anyway... how many of those 40-whatever MB of data could have
never been downloaded for anyone? Of course that's neither here nor
there, I suppose.
Anyway, it's no skin off my nose if the bundle gets deleted or not. I've
probably written 100 lines of C in the entire year. But what I do have a
problem with is the seemingly single-handed decision (well, now I guess
it's triple handed or so) to delete someone else's bundle without a
compelling reason. If that's what Alan wants that's fine -- it's his
playground and his ball. But it doesn't sit right when it's the
intramural squad that wants to take down the nets.
William D. Neumann
---
"There's just so many extra children, we could just feed the
children to these tigers. We don't need them, we're not doing
anything with them.
Tigers are noble and sleek; children are loud and messy."
-- Neko Case
Life is unfair. Kill yourself or get over it.
-- Black Box Recorder
More information about the textmate
mailing list