I’ve started work on an ActionScript 3 sugar. Currently very basic. There are basic Syntax, Itemizers, and some code sensing for the import statement. I’m modeling it after the JavaScript Sugar and PHP Sugar as they languages behave similarly. So I would like the thank the guys working on the PHP sugar because it helped me figure a lot of this stuff out.
i wanted to create an actionscript sugar for espresso since its first release but never found the time to start. great to hear that you are working on it. i think you can save yourself a lot of time when you import the actionscript 3 itemizers and codesense from the textmate bundle.
some time ago i put toghether a small list of “must-haves”. maybe you agree with some of them:
- “build and run” menu item to compile the currently open fla in flash cs3 / cs4
- autocomplete while typing
- live syntax error highlighting
- “tidy up code” menu item which checks the code and completes semicolons or gives out syntax errors
- auto add required imports, remove unused imports
- view help docs for selected word
- premade templates for common code like functions, vars, classes, etc
- icons in the navigator for packages, classes, functions, getters/setters
for later:
- add support to build with mxmlc, ant or flex
please contact me to discuss your plans a little further, maybe i can help!
Your ideas are pretty good. For now I’m focusing on getting the syntax, codesnese and itemizers to a complete-ish state. Converting the ActionScript 3 TextMate Bundle doesn’t work too well out of the box; however I can pick at it and take what I need and get it to work.
After those are complete I plan to focus on the other areas, by order of importance
(This will definitely need to be done with Cocoa Sugars)
- “Build / Run” with CS3 / CS4 /MXMLC (without a doubt the most important)
- Advanced autocomplete (codesense is good but I want it to be smarter.)
- Auto add / remove imports (great time saver)
- Livedoc support (always good to have)
- Live syntax error checking (good to have aswell)
- Icons (this may come sooner depending on what happens)
- Tidy up code (good to have, but its last since
One thing I would really like to add is dynamic codesense / autocompletion for user generated classes. This may not be possible now but as soon as it is, I will jump on it.
But for now just getting the basics down before I get into the more complex.
by advanced autocomplete/codesense I’m talking about a situation like this.
var box:Sprite = new Sprite(); Where box is an object of class sprite, thus has all the member functions of Sprite.
So when ever I type;
box. It till load up a list of method/properties form class Sprite and all inherited methods/properties like so.
box.(graphics)
(addEventListener)
(x)
(......)
I suggest that you not do this. I don’t write AS3, but it would be a huge performance hit for any sizable project.
The best path, and the one I’ll be taking for Ruby, is to A) petition Jan for an API/system that allows us to index the current file’s contents (and possibly, just possibly, depending on how much of a performance hit it would be, the Ruby files in the current Espresso project) for tab completion (function names, varibles, classes, etc), and the B) leave it up to other devs to write Injection Sugars for the systems they want completed. These would include frameworks (Rails.sugar, Merb.sugar, Rack.sugar…), popular libraries (Facets.sugar, Hpricot.sugar), and any other things which add a group of elements which need to be auto-completed.
Thanks for this! This will start off a great new year indeed! Looks like a great start, and could very well be the motivation I need to switch to Espresso (To be honest, I’d not heard of the editor before today, but after seeing it mentioned on MacUpdate and following the link here to find AS3 support, I’m impressed).
I’ve created similar tools for jEdit, and would be happy to help out if you need a hand with any features, etc. Your codesense already seems to be better than anything supported on jEdit to date, but perhaps my build/debugging
I’ve updated the wiki on GitHub with what I have be working on in the various files. The list is far from complete, and anyone is welcome to add to the wiki. Also testing the the sugar and letting me know where it needs improvements is also helpful.
by advanced autocomplete/codesense I’m talking about a situation like this.
var box:Sprite = new Sprite(); Where box is an object of class sprite, thus has all the member functions of Sprite.
So when ever I type;
box. It till load up a list of method/properties form class Sprite and all inherited methods/properties like so.
box.(graphics)
(addEventListener)
(x)
(......)
I suggest that you not do this. I don’t write AS3, but it would be a huge performance hit for any sizable project.
The best path, and the one I’ll be taking for Ruby, is to A) petition Jan for an API/system that allows us to index the current file’s contents (and possibly, just possibly, depending on how much of a performance hit it would be, the Ruby files in the current Espresso project) for tab completion (function names, varibles, classes, etc), and the B) leave it up to other devs to write Injection Sugars for the systems they want completed. These would include frameworks (Rails.sugar, Merb.sugar, Rack.sugar…), popular libraries (Facets.sugar, Hpricot.sugar), and any other things which add a group of elements which need to be auto-completed.
Yes there could be a performance hit. I will definitely be waiting to see what the Jan adds to Espresso that would allow us to do this easily and without compromising performance.
by advanced autocomplete/codesense I’m talking about a situation like this.
var box:Sprite = new Sprite(); Where box is an object of class sprite, thus has all the member functions of Sprite.
So when ever I type;
box. It till load up a list of method/properties form class Sprite and all inherited methods/properties like so.
box.(graphics)
(addEventListener)
(x)
(......)
I suggest that you not do this. I don’t write AS3, but it would be a huge performance hit for any sizable project.
The best path, and the one I’ll be taking for Ruby, is to A) petition Jan for an API/system that allows us to index the current file’s contents (and possibly, just possibly, depending on how much of a performance hit it would be, the Ruby files in the current Espresso project) for tab completion (function names, varibles, classes, etc), and the B) leave it up to other devs to write Injection Sugars for the systems they want completed. These would include frameworks (Rails.sugar, Merb.sugar, Rack.sugar…), popular libraries (Facets.sugar, Hpricot.sugar), and any other things which add a group of elements which need to be auto-completed.
Yes there could be a performance hit. I will definitely be waiting to see what the Jan adds to Espresso that would allow us to do this easily and without compromising performance.
I think you misunderstood me d-:
I was saying that I don’t expect Jan to integrate features that read every imported sourcefile into memory and parse it for syntax / CodeSense data. T4, I hope he doesn’t. I can’t think of any way to do that without a huge preformance hit. Thus, as many commonly-used code libraries as can be should be hand-described in their own Sugars, such as described above (Rails.sugar, etc and whatever the Actionscript variants of such are).
Just a note: Sprite is a built-in class of ActionScript 3. I guess you thought it was a user generated file. I’ll be describing the built-in classes, top-level functions and properties in the sugar.
Just a note: Sprite is a built-in class of ActionScript 3. I guess you thought it was a user generated file. I’ll be describing the built-in classes, top-level functions and properties in the sugar.
That certainly makes sense. It’s worth auto-completing most anything that is distributed in a language’s stdlib.
Just a note: Sprite is a built-in class of ActionScript 3. I guess you thought it was a user generated file. I’ll be describing the built-in classes, top-level functions and properties in the sugar.
now i understand what you mean with “advanced”. to me this looks like a quite normal auto-complete functionality. it would be advanced when the same thing would go for user genereated classes too (flex builder can do that). but as i read now this would be a performance killer.
