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