Hi there,
I've been trying to send this to the dev list, but somehow the message didn't make it to the list.
I'm trying to commit the wonderfull JavaScript Tools Bundle[1] by Andrew Dupont to the repository, but it seems I'm not allowed to commit outside "my" bundle (that would be ActionScript.tmbundle)
Is any of the JavaScript Bundle mantainer (or someone with full access to the repo) willing to commit it?
Tha bundle is fully tested and ready for commit :)
Thanks in advance, and sorry for the OTish.
[1]: http://www.andrewdupont.net/2006/10/01/javascript-tools-textmate-bundle/
-- Ale Muñoz http://sofanaranja.com http://bomberstudios.com
I've been trying to send this to the dev list, but somehow the message didn't make it to the list.
Make sure your using the same address your subbed from to send.
I'm trying to commit the wonderfull JavaScript Tools Bundle[1] by Andrew Dupont to the repository, but it seems I'm not allowed to commit outside "my" bundle (that would be ActionScript.tmbundle)
Is any of the JavaScript Bundle mantainer (or someone with full access to the repo) willing to commit it?
Tha bundle is fully tested and ready for commit :)
Need to avoid committing small bundles like this, if the command and such are generally helpful we should just make them part of the main Javascript bundle. There are bundles that don't do this, but this is where we should head. ;)
Has Andrew given permission for them to be added?
As for the command themselves, I'll let someone that knows something about javascript respond. ;)
On Feb 9, 2007, at 5:59 AM, Michael Sheets wrote:
Need to avoid committing small bundles like this, if the command and such are generally helpful we should just make them part of the main Javascript bundle. There are bundles that don't do this, but this is where we should head. ;)
Has Andrew given permission for them to be added?
As for the command themselves, I'll let someone that knows something about javascript respond. ;)
I wouldn't call a 4MB bundle small ;). I agree though that 5 js code cleanup commands do not qualify for a bundle of their own, but perhaps we would consider adding some of them to the javascript bundle.
This bundle seems to contain jsl binaries for intel and mac separately, so to begin with I would like to see a universal binary there. Second of all, I am not entirely sure that we can include the jsl binaries at all, we would need to check the licenses first. It might make more sense perhaps for the commands to expect the system to have jsl installed, and to prompt their user to appropriate links where they can get jsl.
Also, if all of those are doing code cleanup, perhaps we really only need one or at most two of them, instead of five new commands? Not being a js expert and not having read in detail what each of the commands does, I can't really comment on it. Perhaps some of our js experts can comment on the tools in this bundle.
There also seems to be a hefty custom_rhino.jar file, which I don't know much about.
So to summarize, this bundle has first of all perhaps too many commands, so I'd like to first know whether they are all needed before cluttering the bundle menus further, or whether we can think about the use cases and decide which of there are really the most useful ones or something like that. I would expect the "code cleanup" command to be a single command for each language. Second, this bundle includes a lot of binaries and code from other people/organizations, so I'd like to make sure we have permissions from all relevant parties (starting from the bundle's author) before/ if we include all this in the repository. In some of these files, I even had a hard time finding the licensing information.
Haris
On Feb 9, 2007, at 7:56 AM, Charilaos Skiadas wrote:
On Feb 9, 2007, at 5:59 AM, Michael Sheets wrote:
Need to avoid committing small bundles like this, if the command and such are generally helpful we should just make them part of the main Javascript bundle. There are bundles that don't do this, but this is where we should head. ;)
Has Andrew given permission for them to be added?
As for the command themselves, I'll let someone that knows something about javascript respond. ;)
I wouldn't call a 4MB bundle small ;). I agree though that 5 js code cleanup commands do not qualify for a bundle of their own, but perhaps we would consider adding some of them to the javascript bundle.
This bundle seems to contain jsl binaries for intel and mac separately, so to begin with I would like to see a universal binary there. Second of all, I am not entirely sure that we can include the jsl binaries at all, we would need to check the licenses first. It might make more sense perhaps for the commands to expect the system to have jsl installed, and to prompt their user to appropriate links where they can get jsl.
Also, if all of those are doing code cleanup, perhaps we really only need one or at most two of them, instead of five new commands? Not being a js expert and not having read in detail what each of the commands does, I can't really comment on it. Perhaps some of our js experts can comment on the tools in this bundle.
There also seems to be a hefty custom_rhino.jar file, which I don't know much about.
So to summarize, this bundle has first of all perhaps too many commands, so I'd like to first know whether they are all needed before cluttering the bundle menus further, or whether we can think about the use cases and decide which of there are really the most useful ones or something like that. I would expect the "code cleanup" command to be a single command for each language. Second, this bundle includes a lot of binaries and code from other people/organizations, so I'd like to make sure we have permissions from all relevant parties (starting from the bundle's author) before/if we include all this in the repository. In some of these files, I even had a hard time finding the licensing information.
Haris
This bundle is quite hot. We certainly can't add it to the official repo asis however. I'd like to see what it'll take to add most of it to the official repo though.
Maybe we could just have a setup command that grabs all the necessary files from somewhere and installs them in the right places for you. If we can get the licenses to distribute all this stuff I think it's totally worth adding to the official Javascript bundle.
thomas Aylott — design42 — subtleGradient — CrazyEgg
On 2/9/07, subtleGradient / Thomas Aylott oblivious@subtlegradient.com wrote:
Has Andrew given permission for them to be added?
I emailed Andrew some days ago, and he is ok with this.
He told me that JSmin (the tool used for cleanup) is released under the MIT license, so no problems with it. JSL (the tool used for syntax and error validation) is released under the Mozilla license.
As for the command themselves, I'll let someone that knows something about javascript respond. ;)
The commands are so cool they made some of my fellow coworkers drool (and they code quite a lot of Javascript :)
I wouldn't call a 4MB bundle small ;). I agree though that 5 js code cleanup commands do not qualify for a bundle of their own, but perhaps we would consider adding some of them to the javascript bundle.
My intentions when commiting the tools as a separated bundle were:
* Make the tools available to everyone that want to play with them, without "polluting" the JS bundle for those that don't need them * Get the commands out there for everyone to play with and improve, and * Decide later which (if any) commands could be included in the Javascript bundle
This bundle seems to contain jsl binaries for intel and mac separately, so to begin with I would like to see a universal binary there.
I had already modified the binaries and did some code cleanup. There is a single universal binary now, it is stripped (so it is 1.6Mb), and I'm in the process of adding the corresponding license files with each binary.
Second of all, I am not entirely sure that we can include the jsl binaries at all, we would need to check the licenses first. It might make more sense perhaps for the commands to expect the system to have jsl installed, and to prompt their user to appropriate links where they can get jsl.
JSL, as far as I can tell from what's included in the source, is released under the GPL/LGPL/Mozilla license (MPL). We could look into making it a requirement for the command, and ask the user to install it. It saves us the trouble of keeping up with new versions, but we also lose some control of it, thus inducing potential problems. Nothing to worry too much about, but not to forget about either.
Not being a js expert and not having read in detail what each of the commands does, I can't really comment on it. Perhaps some of our js experts can comment on the tools in this bundle.
That was part of the idea :)
There also seems to be a hefty custom_rhino.jar file, which I don't know much about.
That would be the Rhino Javascript parser, used by the "Compress" command. It is also released under the MPL license.
So to summarize, this bundle has first of all perhaps too many commands, so I'd like to first know whether they are all needed before cluttering the bundle menus further, or whether we can think about the use cases and decide which of there are really the most useful ones or something like that. I would expect the "code cleanup" command to be a single command for each language.
Actually, the two commands *may* be replaced by one. "Compress" and "Minimize" use two different approaches. Compress uses Rhino, while Minimize is a Ruby script that (hopefully) does the same thing. The truth is "Compress" is better at reducing filesize (and may be more bulletproof), but it may not be worth the extra size (Rhino is 700Kb)
In some of these files, I even had a hard time finding the licensing information.
Yep, it was hard, but contacts have been made and agreements have been reached :)
I understand the worries you're voicing (specially considering past "horrors" in the repository), but I'd like to think Allan does not give SVN access to the repo to anybody that just asks and can't tell their GPLs from their MS-RLs :)
Maybe we could create an Experimental JavaScript bundle? That way we play with can play with the tools and include them in the "official" bundle once they are considered worthy of it...
-- Ale Muñoz http://sofanaranja.com http://bomberstudios.com
On Feb 9, 2007, at 2:58 PM, Ale Muñoz wrote:
On 2/9/07, subtleGradient / Thomas Aylott oblivious@subtlegradient.com wrote:
Has Andrew given permission for them to be added?
I emailed Andrew some days ago, and he is ok with this.
He told me that JSmin (the tool used for cleanup) is released under the MIT license, so no problems with it. JSL (the tool used for syntax and error validation) is released under the Mozilla license.
As for the command themselves, I'll let someone that knows something about
javascript respond. ;) The commands are so cool they made some of my fellow coworkers drool
(and they code quite a lot of Javascript :)
I wouldn't call a 4MB bundle small ;). I agree though that 5 js code cleanup
commands do not qualify for a bundle of their own, but perhaps we would consider adding some of them to the javascript bundle. My intentions when commiting the tools as a separated bundle were:
- Make the tools available to everyone that want to play with them,
without "polluting" the JS bundle for those that don't need them
- Get the commands out there for everyone to play with and improve,
and
- Decide later which (if any) commands could be included in the
Javascript bundle
This bundle seems to contain jsl binaries for intel and mac separately, so
to begin with I would like to see a universal binary there. I had already modified the binaries and did some code cleanup. There
is a single universal binary now, it is stripped (so it is 1.6Mb), and I'm in the process of adding the corresponding license files with each binary.
Second of all, I am not entirely sure that we can include the jsl binaries at all, we would need to check the licenses first. It might make more sense perhaps for the commands to expect the system to have jsl installed, and to prompt their user to appropriate links where they can get jsl.
JSL, as far as I can tell from what's included in the source, is released under the GPL/LGPL/Mozilla license (MPL). We could look into making it a requirement for the command, and ask the user to install it. It saves us the trouble of keeping up with new versions, but we also lose some control of it, thus inducing potential problems. Nothing to worry too much about, but not to forget about either.
Not being a js expert and not having read in detail what each of the commands does, I can't really comment on it. Perhaps some of our js experts can comment on the tools in this bundle.
That was part of the idea :)
There also seems to be a hefty custom_rhino.jar file, which I don't know much about.
That would be the Rhino Javascript parser, used by the "Compress"
command. It is also released under the MPL license.
So to summarize, this bundle has first of all perhaps too many commands, so
I'd like to first know whether they are all needed before cluttering the bundle menus further, or whether we can think about the use cases and decide which of there are really the most useful ones or something like that. I would expect the "code cleanup" command to be a single command for each language. Actually, the two commands *may* be replaced by one. "Compress" and
"Minimize" use two different approaches. Compress uses Rhino, while Minimize is a Ruby script that (hopefully) does the same thing. The truth is "Compress" is better at reducing filesize (and may be more bulletproof), but it may not be worth the extra size (Rhino is 700Kb)
In some of these files, I even had a hard time finding the licensing information.
Yep, it was hard, but contacts have been made and agreements have been
reached :) I understand the worries you're voicing (specially considering past "horrors" in the repository), but I'd like to think Allan does not give SVN access to the repo to anybody that just asks and can't tell their GPLs from their MS-RLs :) Maybe we could create an Experimental JavaScript bundle? That way we play with can play with the tools and include them in the "official" bundle once they are considered worthy of it... -- Ale Muñoz http://sofanaranja.com http://bomberstudios.com
Ok! I have now played with this thing and we need it. It's really awesome stuff. Forget about the filesize, it's just really necessary stuff.
I'd really like this stuff to be in the default Javascript bundle. But, adding 4 megs to a default TextMate bundle seems wrong without express Allan permission.
So, let's make an Experimental Javascript bundle and slap this stuff in there.
Yes, we need both the compressor and the minimizer. Maybe with some better name though. One of them actually changes your code to make stuff smaller, the other does not, that's the difference.
Maybe we could create a single command with both actions, but at the very least they should both have the same keystroke to give you the menu.
thomas Aylott — design42 — subtleGradient — CrazyEgg
subtleGradient / Thomas Aylott <oblivious@...> writes:
Ok! I have now played with this thing and we need it. It's really awesome stuff. Forget about the filesize, it's just really necessary stuff.
I'd really like this stuff to be in the default Javascript bundle. But, adding 4 megs to a default TextMate bundle seems wrong without express Allan permission.
I vote no on the 4 MB increase. The *.tmcommand files themselves are surely small, and can easily call out to these tools if they are installed elsewhere. What's the downside to making people do a few extra clicks to actually install the large parts? It's certainly easier for most than going through the hassle of picking up a bundle from SVN.
So, let's make an Experimental Javascript bundle and slap this stuff in there.
No, this is exactly the wrong approach. If this is so unbelievably cool, it should be in the main bundle so that regular users can take advantage of it, without needing to muck with svn, etc. In fact, I think that putting things in Experimental bundles is generally bad, unless their inclusion in the regular bundle could break something else.
So my vote: slap it in the regular javascript bundle, document it in the bundle's help file (it does have one, right?) with installation instructions, and then bring up a way for users to install if you try to run the commands without the relevant external tools.
-Jacob
On Feb 9, 2007, at 4:48 PM, Jacob Rus wrote:
subtleGradient / Thomas Aylott <oblivious@...> writes:
Ok! I have now played with this thing and we need it. It's really awesome stuff. Forget about the filesize, it's just really necessary stuff.
I'd really like this stuff to be in the default Javascript bundle. But, adding 4 megs to a default TextMate bundle seems wrong without express Allan permission.
I vote no on the 4 MB increase. The *.tmcommand files themselves are surely small, and can easily call out to these tools if they are installed elsewhere. What's the downside to making people do a few extra clicks to actually install the large parts? It's certainly easier for most than going through the hassle of picking up a bundle from SVN.
So, let's make an Experimental Javascript bundle and slap this stuff in there.
No, this is exactly the wrong approach. If this is so unbelievably cool, it should be in the main bundle so that regular users can take advantage of it, without needing to muck with svn, etc. In fact, I think that putting things in Experimental bundles is generally bad, unless their inclusion in the regular bundle could break something else.
So my vote: slap it in the regular javascript bundle, document it in the bundle's help file (it does have one, right?) with installation instructions, and then bring up a way for users to install if you try to run the commands without the relevant external tools.
-Jacob
What I meant was that it should be in the default bundle. But since Allan should be the final decider on what major stuff like that goes into the default bundles, I'm saying to temporarily put it in another bundle until we can get Allan's opinion on it.
I think your option is actually better in the short term. Put it in the default bundle now, but leave out the larger bits. Then make it easy for people to install the larger bits if they feel so inclined.
Good plan. Let's do it
thomas Aylott — design42 — subtleGradient — CrazyEgg
On Feb 9, 2007, at 5:33 PM, subtleGradient / Thomas Aylott wrote:
I think your option is actually better in the short term. Put it in the default bundle now, but leave out the larger bits. Then make it easy for people to install the larger bits if they feel so inclined.
Good plan. Let's do it
One more vote on this as well. Even 2.3MB is quite a lot, given that the whole TM binary is 23MB atm, so we are talking about a 10% increase in the file size, so the binaries should definitely be downloadable somehow. Ideally the user should just have to say YES I WANT THIS SO BAD, or say I ALREADY HAVE IT INSTALLED, HERE IT IS. But if these commands are really so cool, we want them in the main Javascript bundle, no questions about it.
Haris
On Feb 9, 2007, at 5:46 PM, Charilaos Skiadas wrote:
On Feb 9, 2007, at 5:33 PM, subtleGradient / Thomas Aylott wrote:
I think your option is actually better in the short term. Put it in the default bundle now, but leave out the larger bits. Then make it easy for people to install the larger bits if they feel so inclined.
Good plan. Let's do it
One more vote on this as well. Even 2.3MB is quite a lot, given that the whole TM binary is 23MB atm, so we are talking about a 10% increase in the file size, so the binaries should definitely be downloadable somehow. Ideally the user should just have to say YES I WANT THIS SO BAD, or say I ALREADY HAVE IT INSTALLED, HERE IT IS. But if these commands are really so cool, we want them in the main Javascript bundle, no questions about it.
Haris
Agreed. All the little stuff will be included. All the big stuff will be downloadable/installable manually and eventually automatically.
thomas Aylott — design42 — subtleGradient — CrazyEgg
On 2/9/07, subtleGradient / Thomas Aylott oblivious@subtlegradient.com wrote:
I have now played with this thing and we need it. It's really awesome stuff. Forget about the filesize, it's just really necessary stuff.
That was my exact reaction when I installed it. Now we're talking :)
I'd really like this stuff to be in the default Javascript bundle. But, adding 4 megs to a default TextMate bundle seems wrong without express Allan permission.
I totally agree. *BUT* the version I have (stripped universal binary, some cleanup) is only 2.3 Mb. It could be even less, as JSL is not the latest version and I have *no* idea how the original binaries were compiled.
So, let's make an Experimental Javascript bundle and slap this stuff in there.
Why not use "JavaScript Tools"? The name already has some exposure, and it would be a nice way of thanking the original author. Also, I think "JavaScript Tools" is a better description of what it does :)
Yes, we need both the compressor and the minimizer. Maybe with some better name though. One of them actually changes your code to make stuff smaller, the other does not, that's the difference.
I think we *really* have to test both commands with some popular JS libraries, and see if they are both needed. If it turns out we need both, it would be übercool to have a command that would minimize the file when first called, and compress the file the second time. I'm thinking about the Ctrl + < command in the Rails bundle (it "cycles" through some snippets when you press it)
Let me know how you'd like to get the bundle (email, http, svn) and I'll send it right away :)
-- Ale Muñoz http://sofanaranja.com http://bomberstudios.com
On Feb 9, 2007, at 5:05 PM, Ale Muñoz wrote:
Yes, we need both the compressor and the minimizer. Maybe with some better name though. One of them actually changes your code to make stuff smaller, the other does not, that's the difference.
I think we *really* have to test both commands with some popular JS libraries, and see if they are both needed. If it turns out we need both, it would be übercool to have a command that would minimize the file when first called, and compress the file the second time. I'm thinking about the Ctrl + < command in the Rails bundle (it "cycles" through some snippets when you press it)
Let me know how you'd like to get the bundle (email, http, svn) and I'll send it right away :)
Actually, I've already tested them both with production code. At CrazyEgg.com we use the compressor in our build process, along with our own obfuscator.
And they really do different enough things that I would always want to run them separately.
Actually, I think the minimizer one would be better suited replacing the ⌃⌥Q keystroke for Unwrap Paragraph / Reformat Compressed. That's an existing standard in many bundles already, having a custom way to reformat the code. Except hack the command to work on the selection or the current line. Then I'll need to commit my Reformat Uncompressed commands too.
If you have the bundle in svn already, send me a link, if you just have a zip or whatever else already, send that. I'm rarin to go!
thomas Aylott — design42 — subtleGradient — CrazyEgg
I totally agree. *BUT* the version I have (stripped universal binary, some cleanup) is only 2.3 Mb. It could be even less, as JSL is not the latest version and I have *no* idea how the original binaries were compiled.
A note… I downloaded the 'official' version of jsl, it's only 500k vs the huge version in the bundle. Should look at why this version is so large. We could also likely get away with just the ppc version no? Rosetta can run it correct?
Charilaos Skiadas <skiadas@...> writes:
I wouldn't call a 4MB bundle small ;). I agree though that 5 js code cleanup commands do not qualify for a bundle of their own, but perhaps we would consider adding some of them to the javascript bundle.
Yes indeed, we don't want to put 4MB of this stuff in the repository, but it'd be great if it could be installed elsewhere on the user's system and then called by these bundle commands, appropriately added to the javascript bundle.
-Jacob
PS: Incidentally, I'm in general in favor of merging some of the smaller bundles that really belong together, and doing some other renaming to keep things better organized, more consistent, and clearer for users:
* There's no reason for Django to have 2 bundles. Also, maybe call this "Python -- Django" ? * OCamlCodeCompletion being 3 bundles is ridiculous. Even one is pushing it, given that the concept is a drastic misuse of snippets for a problem domain they aren't suited to, but 3 is definitely overkill. * JQuery should be renamed "Javascript JQuery" to match the YUI and Prototype bundles * "Tricks" and "Experimental" bundles seem to have an overlapping mission * "Template toolkit" should maybe be called "HTML -- template toolkit" so that people have an idea what it is? * Not sure "web searches" really deserves its own bundle. Why can't it go under the "TextMate" bundle or similar. * should SWeave maybe be called "R -- Sweave"? * I still kinda think 3 GTD bundles is too much * Can we just get rid of Active4D altogether, as something that's only used by one guy? (and take that theme out of the repository, too?) * Change "MIPS" to "Assembler", and then people can put other assembly language syntaxes in the same bundle?
Not all of the above are necessarily the best ideas. Feel free to dispute any of them.
-Jacob
Okay, so I still think a bunch of this should be done, but it didn't get many replies last time. I'll annotate the list a bit. Maybe I can just assume that silence = consent this time? ;)
Jacob Rus wrote:
PS: Incidentally, I'm in general in favor of merging some of the smaller bundles that really belong together, and doing some other renaming to keep things better organized, more consistent, and clearer for users:
- There's no reason for Django to have 2 bundles. Also, maybe call this "Python -- Django" ?
Are any of the Django guys on this list? If so, do you mind merging the bundles?
- OCamlCodeCompletion being 3 bundles is ridiculous. Even one is pushing it, given that the concept is a drastic misuse of snippets for a problem domain they aren't suited to, but 3 is definitely overkill.
I think that someone's working on this
- JQuery should be renamed "Javascript JQuery" to match the YUI and Prototype bundles.
- "Tricks" and "Experimental" bundles seem to have an overlapping mission
Apparently they don't have an overlapping mission, and Allan wants to keep them separate. Okay by me :)
- "Template toolkit" should maybe be called "HTML -- template toolkit" so that people have an idea what it is?
- Not sure "web searches" really deserves its own bundle. Why can't it go under the "TextMate" bundle or similar.
I still sort of feel this way. Maybe it belongs in "tricks" then, or something?
- should SWeave maybe be called "R -- Sweave"?
- I still kinda think 3 GTD bundles is too much
What ever happened to the plan to get rid of "GTD" and change the name of "GTD2" to just "GTD"? Or am I just imagining that that was the plan?
- Can we just get rid of Active4D altogether, as something that's only used by one guy? (and take that theme out of the repository, too?)
I'm not sure that Aparajita guy is subscribed to this list. Maybe someone should just email him directly and ask about this?
- Change "MIPS" to "Assembler", and then people can put other assembly language syntaxes in the same bundle?
Is anyone opposed to such a change? I think it would keep things cleaner, but maybe I'm wrong about that.
Not all of the above are necessarily the best ideas. Feel free to dispute any of them.
-Jacob
- Change "MIPS" to "Assembler", and then people can put other assembly language syntaxes in the same bundle?
Is anyone opposed to such a change? I think it would keep things cleaner, but maybe I'm wrong about that.
Actually it probably should be
Assembler/MIPS
as it is just a question of time before other CPU types might be added, like
Assembler/SX Assembler/78Cxx Assembler/68k Assembler/Z80
Gerd
Gerd Knops wrote:
Jacob Rus wrote:
- Change "MIPS" to "Assembler", and then people can put other assembly language syntaxes in the same bundle?
Actually it probably should be `Assembler/MIPS`, as it is just a question of time before other CPU types might be added, like
Assembler/SX Assembler/78Cxx Assembler/68k Assembler/Z80
Yes, exactly. But is there any reason for each to have its own bundle?
I think they are better off all in the same bundle. But maybe others disagree?
On Feb 26, 2007, at 5:15 PM, Jacob Rus wrote:
Gerd Knops wrote:
Jacob Rus wrote:
- Change "MIPS" to "Assembler", and then people can put other assembly language syntaxes in the same bundle?
Actually it probably should be `Assembler/MIPS`, as it is just a question of time before other CPU types might be added, like Assembler/SX Assembler/78Cxx Assembler/68k Assembler/Z80
Yes, exactly. But is there any reason for each to have its own bundle?
I think they are better off all in the same bundle. But maybe others disagree?
Depends on how much momentum TextMate gains for Assembler use, especially in the Micro-Controller arena. Typically each Micro- Controller has a leading development kit. That results in upload and run commands, templates, custom snippets, probably completion etc. So yes, for advanced use as a development environment individual bundles would be beneficial.
Gerd
On 26. Feb 2007, at 22:37, Jacob Rus wrote:
PS: Incidentally, I'm in general in favor of merging some of the smaller bundles that really belong together, and doing some other renaming to keep things better organized, more consistent, and clearer for users:
- There's no reason for Django to have 2 bundles. Also, maybe call this "Python -- Django" ?
Are any of the Django guys on this list? If so, do you mind merging the bundles?
Yeah, these two should be merged. I think Michael Sheets was actually, at some point, working on a Django replacement bundle!?! But then, what is he not working to replace? ;)
- OCamlCodeCompletion being 3 bundles is ridiculous. Even one is pushing it, given that the concept is a drastic misuse of snippets for a problem domain they aren't suited to, but 3 is definitely overkill.
I think that someone's working on this
Yes, I think when the newer completion bundle from David Powers has been deemed useable enough, the other (snippet-based completion) bundles will go.
- JQuery should be renamed "Javascript JQuery" to match the YUI and Prototype bundles.
It should. I’d considered doing it myself :)
- "Tricks" and "Experimental" bundles seem to have an overlapping mission
Apparently they don't have an overlapping mission, and Allan wants to keep them separate. Okay by me :)
As of such, might be better to move all this experimental stuff to another location on the repository.
- "Template toolkit" should maybe be called "HTML -- template toolkit" so that people have an idea what it is?
Template Toolkit is a Perl module, so it might be more correct to name it: “Perl Template Toolkit” to follow the naming convention. But I am not entirely sure in which contexts the toolkit is used.
- Not sure "web searches" really deserves its own bundle. Why can't it go under the "TextMate" bundle or similar.
I still sort of feel this way. Maybe it belongs in "tricks" then, or something?
We could also retire some of the stuff (all but the Shorten Amazon Link) -- these all open up an external browser, and for that, I’d say there are better / system-wide tools (Quicksilver, Services). For TextMate, commands like the Haris’ Google-lucky command, Brett’s Wikipedia stuff, etc. is much better.
- should SWeave maybe be called "R -- Sweave"?
Or LaTeX Sweave?
- I still kinda think 3 GTD bundles is too much
What ever happened to the plan to get rid of "GTD" and change the name of "GTD2" to just "GTD"? Or am I just imagining that that was the plan?
Yes, I think Mike said he needed something like 14 days to see if GTD2 was good enough to fully replace GTD -- Mike, are you there?
- Can we just get rid of Active4D altogether, as something that's only used by one guy? (and take that theme out of the repository, too?)
I'm not sure that Aparajita guy is subscribed to this list. Maybe someone should just email him directly and ask about this?
I think it is fine to keep it for now -- when bundlecasts become a practical alternative to the central repository, we can re-evaluate which bundles should be in the central repository.
- Change "MIPS" to "Assembler", and then people can put other assembly language syntaxes in the same bundle?
Is anyone opposed to such a change? I think it would keep things cleaner, but maybe I'm wrong about that.
With the categorization effort [1] I am moving away from presenting bundles as one flat list. This means it will be better to not merge too many bundles, as viewing bundles will (in the general case) be limited to one category (e.g. assembler), and it will thus be better for the potential 68K developer to just install the 68K bundle, rather than have to install an umbrella assembler bundle.
[1] http://lists.macromates.com/pipermail/textmate-dev/2007-February/ 008240.html
On Feb 27, 2007, at 1:22 AM, Allan Odgaard wrote:
- "Tricks" and "Experimental" bundles seem to have an overlapping mission
Apparently they don't have an overlapping mission, and Allan wants to keep them separate. Okay by me :)
As of such, might be better to move all this experimental stuff to another location on the repository.
What is the current process for beta bundles?
I'm working on a new version of the Ruby syntax. It's called Ruby Experimental and is in the experimental bundle. It's not a pure replacement yet since it just includes the Ruby syntax instead of duplicating and modifying the existing Ruby syntax.
There's also a beta HTML bundle being worked on.
Should we have an explicit BETA bundle for working on new versions of existing things? Should we include the new syntax in the existing bundle with a BETA tag or something?
That option seems to make the best sense actually. Unless anyone seriously objects, I'm going to move Ruby Experimental into the Ruby bundle and make sure that you can only get at it by explicitly selecting it.
I'm not sure if that option would work for HTML2 since the beta HTML2 bundle contains way more than just a new syntax.
thomas Aylott — subtleGradient — CrazyEgg — sixteenColors
On 27. Feb 2007, at 15:03, Thomas Aylott (subtleGradient) wrote:
[...] Should we have an explicit BETA bundle for working on new versions of existing things? Should we include the new syntax in the existing bundle with a BETA tag or something?
I think we should make an explicit BETA branch in the repository -- many users checkout the full repository and gets stuff that may trick them, especially that (experimental stuff) which overload common keys (like e.g. the Experimental LaTeX which redefine the page up/down and home/end keys for text.tex.latex).
Unless anyone seriously objects, I'm going to move Ruby Experimental into the Ruby bundle and make sure that you can only get at it by explicitly selecting it.
Well, you can only get at the PHP syntax by explicitly selecting it, yet many users still do so ;)
I opt for not even having this stuff available to users who did not manually select to checkout the beta branch.
Could you btw make a case for the new Ruby syntax? I never figured out what problem it was supposed to solve.
On Feb 27, 2007, at 1:22 AM, Allan Odgaard wrote:
- should SWeave maybe be called "R -- Sweave"?
Or LaTeX Sweave?
Sweave is more R than LaTeX I would say. In particular, it is theoretically possible to Sweave in HTML instead of LaTeX.
Further, most LaTeX users have never heard of Sweave, and most R users I would say have.
I've been thinking for some time of perhaps merging the Sweave stuff into the R bundle.
Haris Skiadas Department of Mathematics and Computer Science Hanover College
On Tue, 27 Feb 2007, Allan Odgaard wrote:
- OCamlCodeCompletion being 3 bundles is ridiculous. Even one is pushing it, given that the concept is a drastic misuse of snippets for a problem domain they aren't suited to, but 3 is definitely overkill.
I think that someone's working on this
Yes, I think when the newer completion bundle from David Powers has been deemed useable enough, the other (snippet-based completion) bundles will go.
Well, I'm not quite sure what David's vision is for the OCaml Completion bundle he's working on, but I can only hope that it's a better one than that of the latex/ruby bundle style completion, which I find to be pretty useless.
Now, OCaml does have an advantage here in that the default mode of operation is to use modules and not classes, allowing for an easier narrowing of possible completions in most cases, but still the notion of having to hit escape 15 times to get the right function, and then to not have the parameters appear as well is, frankly, a step (or three) in the wrong direction.
Of course, at the moment it doesn't appear to do anything, and one of the commands relies on cmigrep which isn't included with the bundle, so who knows where it's going...
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
On Feb 27, 2007, at 11:59 AM, William D. Neumann wrote:
On Tue, 27 Feb 2007, Allan Odgaard wrote:
- OCamlCodeCompletion being 3 bundles is ridiculous. Even one is pushing it, given that the concept is a drastic misuse of snippets for a problem domain they aren't suited to, but 3 is definitely overkill.
I think that someone's working on this
Yes, I think when the newer completion bundle from David Powers has been deemed useable enough, the other (snippet-based completion) bundles will go.
Well, I'm not quite sure what David's vision is for the OCaml Completion bundle he's working on, but I can only hope that it's a better one than that of the latex/ruby bundle style completion, which I find to be pretty useless.
Now, OCaml does have an advantage here in that the default mode of operation is to use modules and not classes, allowing for an easier narrowing of possible completions in most cases, but still the notion of having to hit escape 15 times to get the right function, and then to not have the parameters appear as well is, frankly, a step (or three) in the wrong direction.
Of course, at the moment it doesn't appear to do anything, and one of the commands relies on cmigrep which isn't included with the bundle, so who knows where it's going...
William D. Neumann
option-escape in Ruby now does an intelligent completion menu. option-escape in CSS, HTML & Prototype Js now does a menu too. Way totally crappy compared to xcode and CSSEdit, but better than nothing.
thomas Aylott — subtleGradient — CrazyEgg — sixteenColors
I have committed the Javascript Tools bundle to bundleforge.
Trac: http://dev.bundles.bundleforge.com/browser/trunk/bundles/ JavaScript%20Tools.tmbundle SVN: http://bundles.bundleforge.com/trunk/bundles/JavaScript% 20Tools.tmbundle RSS: http://feeds.feedburner.com/BundleForge ZIP: Unavailable
Only available through SVN at the moment. I'll add a zip version at some point.
If there is anything wrong with the bundle, add a ticket to the bundleforge Trac.
thomas Aylott — subtleGradient — CrazyEgg — sixteenColors
On 2/15/07, Thomas Aylott (subtleGradient) oblivious@subtlegradient.com wrote:
I have committed the Javascript Tools bundle to bundleforge.
Thomas... did you receive the ZIP I sent you with the bundle?
I made some tweaks to the bin folder (namely 'lipo'ing the two jsl binaries and stripping them) and Commands (made them use webpreview).
Take a look at your "Junk" folder. Spam filters are not really friendly to my other email address (something to do with "bomb" not being a politically correct word :)
Otherwise, good job! The Javascript Tools is truly a gem :)
-- Ale Muñoz http://sofanaranja.com http://bomberstudios.com
-
Ale Muñoz -
Allan Odgaard -
Charilaos Skiadas -
Gerd Knops -
Jacob Rus -
Jacob Rus -
Michael Sheets -
subtleGradient / Thomas Aylott -
Thomas Aylott (subtleGradient)
-
William D. Neumann