ActiveState recently released a new version of their IDE and editor, Komodo. For the first time in several years and many versions (back to at least v6.x), I do not have an update to my Komodo-CFML language extension that works with this new version. Some of the updates in Komodo v11 move away from a couple of capabilities that are crucial for my extension to install and work. As a result, at least for the time being, any plans to continue to support continued development of Komodo-CFML (or even compatibility with this and future versions of Komodo) are on hold.
I’m disappointed, in large part because some of the other updates in Komodo v11 are really impressive. Without support for the language I primarily use the editor for, though, it makes no sense for me to update to this new version.
I had a couple of forum conversations with the Komodo team during the pre-release phase of Komodo v11. I am cautiously optimistic that there might be a path forward. Until then, I’m poking around a bit for alternatives and (so far) coming up mostly empty on one key feature that Komodo + my CFML extension offers: tag-specific attribute help (e.g., if you are in the middle of CFML tag, the code intelligence feature offers attribute suggestions specific to that tag and is aware of which attributes are already in place on the tag) and attribute-specific help (e.g., if you are editing an attribute of a CFML tag which supports a specific set of valid values, those values are presented as possible choices). This makes it fast, easy, and nearly error-proof to get attributes and their values right.
Anyone with recommendations on potentially viable alternatives? Comments are open (at least for a bit, until the spambo[ty]s take over) and suggestions are welcome.
Things on the Komodo-CFML front have been pretty quiet here of late, but that’s not because nothing has been going on. Several months ago, as I wrestled with some odd behavior I was seeing with the extension under then-new Komodo v9, I came to the conclusion that there were a couple of fundamental problems with the approach I had taken in tokenizing CFML (used in Komodo to provide syntax colorizing). Furthermore, that approach appeared to make it nearly impossible to do much in terms of any sort of code intelligence-type help.
So… I started over. Completely. Threw everything out and started from the ground up, building an entirely new version of the extension. (Actually, I started over three times, trying to make sure I had a better approach.) At one point, I got stuck waiting for resolution of a bug relating to how Komodo creates the skeletons of extensions.
At this point, I am very close to having this completely-rebuilt version ready to release (probably as a v0.2.5). I’ve tried to make sure it provides everything the current v0.2.4 does in terms of syntax highlighting, but it also has a couple additions:
- completely reworked DTDs for CFML + HTML5 (for both CFML v10 and v11), with content models that provide better and more consistent access to CFML tag and attribute completion
- CFML language keyword, scope, and function name completion (this is what I started working on and ended up heading down the rabbit-hole that led me to scrap everything and start over)
- macros for CFML help for the word under the current caret position and for CFML comment/uncomment region that work in a manner consistent with Komodo’s built-in comment/uncomment region (more on this at some later date)
So… I’m close. Close enough that I have been using this new (still evolving) version for my daily development work for several weeks. I’m waiting for one additional Komodo bug to be resolved (hoping it will be included in Komodo v9.3, which is in the nightly-build prerelease stage at this point). I will post something here when I release it, as well as making it available through the Komodo packages repository.
Version 0.2.4 of my language extension supporting CFML for ActiveState’s Komodo IDE/Edit is now available. This update represents a minor bump in the version number but also represents more work behind the scenes than any update in recent memory, as all of the plumbing in the extension has been replaced so that it will work with the forthcoming Komodo v9 releases while still working with Komodo v8.x in addition to the changes below.
A Quick Summary of Changes
In addition to the rework noted above to support Komodo v9, this update provides the following changes:
- Tag and attribute support for Adobe ColdFusion v11
- Numerous updates and fixes to the tag and attribute support for Adobe ColdFusion v10
- Switched to cfdocs.org for CFML-specific language help
- Includes a small set of CFML-specific macros (look for “CFML Tools” in Komodo’s Toolbox panel) and puts the scaffolding in place for language-specific macros, snippets, abbreviations, etc.
- A minor change to the syntax highlighting applied to CFML comments occurring within function calls (very edge-case-ish)
A Note About Installation/Upgrading
With this update, you will notice that the structure of the name of the editor extension file itself has changed. Where in the past, the editor extension file was named cfml-0.2.3-ko.xpi, this version is named komodo-cfml-0.2.4a0-ko.xpi. There are two changes there to note:
- The base part of the file name has changed, primarily as part of the reworking of the basic structure of the editor extension for compatibility with Komodo v9; and
- I have changed the embedded versioning information for the extension so I have a bit more flexibility in how I keep track of updates and additions to the extension.
With these changes to the name of the editor extension file, you will want to explicitly uninstall whatever version of Komodo-CFML you may currently be using and then install this new version to avoid any sort of potential confusion within Komodo about how CFML files are to be handled.
The updated version of the extension is available for download:
As always, comments and follow-up are welcome here or on the Komodo-CFML page.
I spent a bit of time today playing with Atom, and it does not suck. I have to admit I went into it with low expectations.
Things I like (in no particular order):
- a UI that obviously is designed to support largely keyboard-driven interaction (e.g., it is very straightforward to turn on/off soft-wrapping of text, something that I need for whatever I use for my Q&D text editing, as soft-wrap for drafting text = necessary while soft-wrap for any sort of code = worse than bad),
- a language mode for CFML (thank you, Adam Tuttle) already available,
- availability of Emmet as a package,
- a reasonably-polished preferences UI that makes it simple to configure.
Perfect? Not by a long shot. But good enough to convince me that I need to poke a little further before I write it off.
It is time: I’m standing up a couple of new development systems, so I am going to use Tomcat 8 and Java 8 as the basis for deploying Railo and Adobe ColdFusion 10 on them. This is the first time I’ve done anything with either Tomcat 8 or Java 8 as the base for the application server stack but with Java 7 set for EOL this (I first wrote “next”) year, the timing for moving seemed appropriate.
I have Railo deployed and running without issue on the first of the two systems, and have encountered no issues at all to this point.
I will blog a bit in the near future to describe my approach and a couple of minor Tomcat differences I have found.
Updated 2014-01-02: Well, that didn’t take long to go sideways… I spent several hours this afternoon trying to deploy ColdFusion 10 on Tomcat 8, and so far have been unsuccessful. I can get the WAR to unpack, but the application simply refuses to start with a very non-specific error in the Catalina log file that (I’m guessing here) appears to indicate an incompatibility with Tomcat 8 in ColdFusion 10. More to come, but my next run at this will probably be to drop back a step or two and try deploying on Tomcat 7 and Java 8.
Updated 2014-01-03: Moving forward again. As of this morning, I now have both Railo 4 and ColdFusion 10 deployed against Tomcat 7 and Java 8.