At the moment, Aptana has separate "editors" for HTML, javascript, CSS, etc. This doesn't seem like a maintainable direction long-term. I'm very frustrated right now by the lack of support for Cold Fusion. At the moment, to add general CF support to Aptana I need to learn java, create a new editor instance and all of the BS that goes with that, then fight with it for several weeks. Cold Fusion is just another tag-based language, and you already know how to parse those. You know how to render them, colorize them, fold them, etc. All you really need is the tag definitions for this language. Aptana should have 1 editor. Not Editor: JS, Editor: CSS, Editor: HTML, etc.. The options in the preferences should be for how the editor treats different installed languages. Cold Fusion is an intensely powerful engine. In a single ColdFusion document I can mix and execute any of the following languages. In other words, the lexer might have to deal with all of these in a single editor instance: CFML, (including CFScript), HTML, javascript, actionscript, SQL, XML, CSS, Spry, and even PHP and Ruby!!! (http://corfield.org/blog/index.cfm/do/blog.entry/entry/ColdFusion_8_running_PHP ) Since CF can create files, run compilers, etc. as well, a CFML document could conceivably contain PERL, C+, C#, VB, or any other language as well. For example, PERL does (well, I haven't tested CF8 actually...) a better job with parsing huge text files than CF does. CF isn't optimized for that kind of work. One of my projects involved parsing 500MB flat data files and mining it in combination with SQLS data. There were 1000's of files. I used CF to generate PERL scripts dynamically, then wrote those scripts to files and executed them, all from a scheduled task. Aptana's lexer should be recognizing all the different languages it knows about within a document and dealing with them intelligently. Keep in mind here that, like PHP, CF is normally used to generate other languages such as SQL, HTML and javascript. The lexer should be smart enough to know that if I'm adding a CF tag between two <script> tags, for example, it's not javascript. CFEclipse fails to show the tag completion and insight in cases like this. I posted this idea to Trac, but I don't see it on here. If I could upload an XML file that contained general language information, (regex's for parsing the tags or script, version info, tag "categories", category-level colorization info, etc.), a body of tag definitions which should contain the tag name, short description, full reference for the tag itself, links to "guide"-type info (as opposed to the tag reference), then all of the available attributes and their possible values, required/optional status, detailed reference info for that attribute, etc. This tag definition should also include an XML-based definition for a GUI tag editor. Homesite does this through something they called "wizml". You can find all of the wizml files in your Homesite folder if you have it installed. These tag editors include a help window that displays the tag reference info, though it wasn't as useful as it could have been. It would have been great if the help window scrolled automatically to show the detailed info for the current attribute you are editing, updating each time focus shifts. BTW, your code insight/completion should be more intelligent. If a tag has an attribute that is required, then the tag should be generated with those attributes. If I'm within a tag attribute and hit tab it should go to the next attribute. Some tags have a required attribute, then different sets of required attributes based on your first choice. Same deal here. I want to type CFFi and the editor gives me <cffile action=""> with all of the options for the action attribute. When I choose "read", the editor should give me <cffile action="read" file="" variable="">. When I tab to the "file" attribute I want a file chooser to pop or have that option in the context menu. When I hit enter the cursor should be inside the "variable" attribute so I can just start typing the variable name. The handlers (color chooser, file chooser, datasource chooser), order, etc. can all be specified within the tag definition. You should start supporting databases as well. Wizml also allowed you to create code-generating wizards. I once built a quick wizard that would let me build a simple query then dump the results to an HTML table. Using just wizml my wizard lets you choose a datasource, a table and a list of columns, and when you hit the go button it creates the CFQuery tags and the table code, including the loop over the variables. Since I can extend that wizml file easily, I can improve on this over time. The language is flexible enough to create entire applications this way. Heck - it would be neat to be able to generate an ANT script through a simple dialog like this. Choose a list of files from FTP, local, etc., choose some options and you have a build file. Here's the thing: If you take an approach like this it could support frameworks easily too. A JQuery, prototype, ext, yui, dojo, mootools, etc. language pack could possibly "extend" the javascript definition if "extending" is even necessary. A coldbox, transfer or coldspring pack could extend the ColdFusion pack. This offers framework writers the ability to provide incredibly good support for their framework as an Aptana plugin. Imagine having intelligent framework-tag-specific code insight and completion... They could also include GUI tag editors, etc. all from an XML file. Since it's all XML you can let everyone else do all the work!! This is a really good thing for you guys in the long run. You can spend all of your new-found spare time building a nice application that lets us develop these language packs easily This should include being able to generate GUI dialogs,etc.