Komodo-CFML: A quick status update (2014-11)

It’s been a bit since I’ve said anything here about Komodo-CFML, and thought a quick update would be appropriate.

As of last weekend, I finally was able to get a version of Komodo-CFML to work successfully on the version 9 alpha builds of Komodo IDE ActiveState has made available beginning earlier this year. I had hoped this not be a big deal, but it ended up taking quite a bit more time and effort than I had hoped. In the end, I resorted to rebuilding the plumbing for the language extension from the ground up in order to get it to work. So, that’s done (and I am currently using v9 with Komodo-CFML as my primary CFML editor on a daily basis).

With that hurdle out of the way, my intent is to get back to implementing tag/attribute support for both Adobe ColdFusion 11 and Railo 4.2. I’m also including a handful of useful (to me, anyway) macros with the language extension. I’ve made a small handful of minor tweaks to the language syntax highlighting, most of which are in the handling of CFSCRIPT syntax as I use it more and more rather than tag-based coding.

I’m hoping to have a version 0.2.4 with all of this available by the late November timeframe, shooting for something around Thanksgiving. If you are using Komodo-CFML and want to use it with the early versions of Komodo IDE v9, let me know in the comments below and I will send you my current working version with v9 support.

OS X Yosemite: First thoughts

I upgraded my MBP (a 15-inch, early 2011 model) to OS X Yosemite on Friday morning, and at this point I am closed to being finished with getting software installed, etc. I typically move between versions of OS X with a clean install and then re-install software and restore files (as needed). It’s not necessarily an approach that would work well for everyone, but it works for me and helps ensure I have a reasonable clean system.

My first thoughts, in no particular order:

  • Helvetica Neue as the primary UI font is going to take some getting used to. My MBP is a couple years old, and is not a Retina device; that has a big impact on how it renders. I particularly notice the difference in the menu bar and in context menus. It simply does not render as clearly and legibly as the font OS X has historically used there.
  • The flat UI will also take some getting used to, but I think I like it, in general, for window decorations, UI controls, icons, etc.
  • I am not crazy about the shift to brighter colors for UI elements and icons. I would characterize many of them as close to garish. I tend to like understated UIs (the theme of my blog will attest to that) and while the flat aspects of the UI head in that direction, the colors most certainly do not. The blue used for UI elements, folder icons, etc., is particularly bad in this regard. The second UI tweak I made was the shift to graphite for basic UI appearance (which unfortunately does nothing for the blue folder icons); the first was to shift the dock to the right side of the display and to have it auto-hide to slide the mass of bright colors out of sight. I hardly ever use the dock (thank you, apps like QuickSilver and Alfred!), so this is something I would do anyway, but I don’t miss the explosion of bright colors from the dock.
  • Transparency and effects: I haven’t decided about these, but in general they feel like a bit much to me. What benefit, for example, is there to having the blue of several selected files in a Finder pane bleed through the context menu when I right-click on them? There are places where I like a bit of window transparency but some of the transparency implemented here feels gratuitous.

My overall general impression: a mixed bag. This is the first OS X version I’ve installed (going back to when I started with OS X Leopard) where I have not had an overwhelmingly positive reaction to the UI evolution.

I’ll follow up a bit after I’ve been on Yosemite for a couple weeks with additional impressions. I’m curious to see how/if these impressions evolve with the passage to time and usage. The other aspect of this is that the system I updated is my own laptop; I have two other MBP’s I use for work and I don’t have any near-term plans to update them… I will be switching between 10.10 and 10.9 on a daily basis, which will likely bring the differences into sharp contrast.

Base16-based Schemes for Komodo

I’ve been working intermittently on a small set of color schemes for ActiveState Komodo based on Chris Kempson’s Base16 color palette. These have reached a point where I feel OK sharing them for others to use, if interested:

I should point out that these are not “pure” Base16 schemes as there are individual settings in each theme which do not hold completely to the Base16 palettes. In most cases, these are settings where I have tuned particular settings for different contrast (e.g., comments, in at least one of them) based on my own preferences. I should also note that, based on my own tuning, I have not looked closely at setting up templates to create these with Mr. Kempson’s related Base16-Builder project but I plan to go down that road in the near future to see if that is workable.

It’s probably also worth pointing out that, for the most part, any language-specific color settings in these schemes are focused primarily on the languages I use (mostly Web-related stuff) so if I’ve missed your languages or your languages don’t seem to follow the Base16 palette, you may want to do some tweaking yourself. I’m also willing to factor those types of changes back into these as they evolve, hopefully both toward use of the Base16-Builder but also so they can be shared via Komodo’s Resources.

Edit 2014-05-14: These schemes specify Adobe’s Source Code Pro for use as the monospaced font. If you don’t have this font installed, you’ll almost certainly want to switch to your font of choice as your first tweak.

Adobe ColdFusion Docs: A better way?

I’m not a fan of the structure the Adobe ColdFusion (ACF) team has moved to for documentation for the recent versions of their product.

A bit of background

With the recent (late May 2014) release of ACFv11, there are now three versions of ACF in which I have varying degrees of interest:

  • v9: we are in the final stages of moving our last app from a shared v9 server to one of our dedicated v10 servers,
  • v10: our entire dev environment is based on v10, and all of our apps with the noted exception above run on v10 in production, and
  • v11: the recent release we’ve watched from a distance as we weigh whether to continue with ACF in the future or shift to Railo as our CFML engine.

My team has used ColdFusion since its Allaire v4 days, and have historically had multiple versions in play across our development and production environments, so the above situation covering three versions is very typical for us. In fact, having all of our dev and production environments based on a single version of ACF as we (almost) do now represents the first time in at least 10 years we’ve been able to achieve this. I don’t believe we are unique in this: any developer moving between versions of the product (or even considering such a migration) will be working with at least two versions of the language and/or the documentation before and during their migration effort.

In addition, I built and continue to maintain a CFML language mode for ActiveState’s Komodo IDE and Edit editors, providing syntax highlighting and tag/tag attribute completion. The tag/tag attribute completion is specific to each CFML version, allowing the user to designate which version of the language is to be used as the basis for which tags and which attributes are to be provided as options to the user. I rely heavily on version-specific documentation to build each of these version-specific implementations.

The problem with the current wiki approach

In recent versions of ACF up through v9, each version had comprehensive documentation sets available both online and as downloadable PDFs. Each of these documentation sets were separate and distinct, and the online versions made it very straightforward to shift between versions. With v10, there is a downloadable PDF version of the documents (thanks to Adam Cameron for pointing me toward those) but the only references to it are not particularly easy to find (search the wiki for “archive” — how obvious is that if you are looking for v10 documentation?). Googling for “adobe coldfusion 10 documentation” does not yield that set of documents in the first page of results. Further, there does not seem to be an online version of some portions of the v10 (such as the tag/function reference). The current online version of the documentation is maintained as part of a wiki that does not contain discrete sections for different versions of the product or language, and for the most part appears to be focused on v11.

The old version-specific implementation of the online docs has the tremendous benefit to the user of being crystal clear as to what capabilities are available in a given version of the language (e.g., which attributes are available for a given tag, what functions/function arguments are available). If I am working on an app currently running on version “x” of ACF, I typically want to see only the version “x” documentation for that tag.

The current wiki-based documentation set, however, does not have that clear distinction between versions of the product or language. This makes differentiating between versions for tags, attributes, supported attribute values, functions, etc., in terms of what is valid and supported between versions far more challenging and error-prone than in previous versions. If I care about the v10 implementation of the cfzip tag, for instance, I have to either use the off-line version of the docs or make sure I look at the “history” portion of the relevant tag page and then mentally remove the new attributes added for v11 (“password” and “encryptionalgorithm”, in this particular case) as I scan down through the attribute documentation — particularly given that there is nothing within the description of the individual attributes indicating their recent addition in v11 (and in the case of the “password” attribute, it seems to be missing altogether from the attribute list).

A better approach?

It seems to me that a better approach would be for separate, discrete version-specific sections within the wiki. The language reference — along with the supporting documents identifying additions, removals, and deprecations — is one example of where this would make the documentation much easier to use. The v10 portion of the reference would always be specific to v10 and would not (should not?) need to contain any v11 content. The v11 portion of the reference would presumably start as a clone of the v10 portion of the documentation, and could evolve along with the language as v11 was developed. As work on v12 is started, the v11 portion would be cloned as a draft and evolve independently from the sections covering previous versions.

The current wiki approach is likely to get more and more unwieldy as additional versions of the product and the language are covered within the current wiki structure. Take the page listing deprecations and removals as an example. Besides being in drastic need of updates as of this writing for completeness and currency with v11, this page — based on its current structure — will get more and more unwieldy as additional versions have to be covered: more rows to cover features being deprecated or removed, and more columns for subsequent versions? The current approach just does not seem to scale for pages such as this.

Note that I am not taking issue with the use of a CMS or wiki for the documentation itself as much as what I see as a poor decision of how to structure the documentation within the tool the ACF team selected.

Finding documentation for earlier, but still-supported, versions of a product should not be difficult but in this case it is getting harder. I’d like to believe the ACF documentation team will recognize this and restructure the documentation set before it collapses under its own weight and degenerates even further in terms of being usable and useful.

And the off-line docs?

The current wiki structure — which seems to be focused mostly on the current language version — also raises the question for me as to whether a similar set of downloadable v11 references will be made available now that the product is available or as the wiki gets refocused on v12 (presumably in the near future, immediately after all of the existing v9/10/11 bugs have been resolved). That’s a separate but important and relevant question. I hope they do continue making that format available, as those downloadable PDFs have repeatedly proven valuable for me and my team at various times.

Komodo-TaskJuggler v. 0.1.2

I’ve been using TaskJuggler a bit more at work recently to develop and maintain project schedules, and decided it was time to do a bit more work on my Komodo extension for the TaskJuggler language. This update doesn’t have anything earth-shaking, but does address a few of the more glaring items on my to-do list:

  • User-defined macros are now syntax-highlighted in the same manner as system macros like “projectstart”.
  • More complete highlighting for secondary keywords and column identifiers used in the various types of reports.
  • The “up” and “down” suffixes used to control column sorting in reports are now highlighted.
  • Fixed a couple highlighting oddities related to the overlap between attributes and report column identifiers (where there is a conflict, attributes win).
  • Some minor cleanup in the mode’s UDL file to remove unused kruft leftover from how Komodo sets up projects.

Download the updated version: taskjuggler-0.1.2-ko.xpi