There is now keystroke support in netWindows.
Idea: an HTML post-processor.
This is really an extension of what NW currently does. The loading process recursively parses each node in the tree in order to discover element definitions. Extending this metaphor (replacing some declaration with another representation of it's symbolic reference), it would be entirely possible to devise an HTML post-processor engine. Using some combination of recursive tree walking and regular expression matching, it should be fairly straight forward to create a language for creating entity definitions and then replace them in the document once it's loaded. For example, equations or code snippets. More work could even yield a client-side conditional include type of functionality.
So here's how it might work in practice: I've got a really long name that I use all over a given document, which could be something like "Robert Alexander Russell" (me). Writing that over and over again would really suck. Instead, if you could just put an abbreviation for it in (say, [[rar]]) and then correlate this with the full string, it wouldn't be hard to do replacement once the page loads. Heck, it'd be cake.
Now suppose I've got a variable that I want to represent in the document, say a variable T. In order to get T to look right in HTML, it might have some extra formatting associated with it's use as a variable, like so:
While regular expressions in editors can ease changes should the class name change, or we want to use a div and not a span, the fact remains that the margin for error is pretty high. If we can just write something like [[T]] and have the previous string inserted for it, then we gain something quite useful for long technical documents.
Better yet, removing portions of a document based on certain criteria become possible with this approach. All we would need would be something like a directive, perhaps:
[[#ifdef myvar]] where
[[#define myvar]] type of a symbol.
Honestly, I'm not sure that this approach buys us much more than a codified way of doing the trivial. While setting up something like this isn't hard for custom stuff, why bother? Might be more powerful and useful to write it once and leverage it moving forward...
Done with exams... now onto the rest of life that I've been neglecting for months, like figuring out how I'm going to pay for school, rent, and food all at the same time...not to mention Christmas presents.
I'm so tired.
I've been starring down probability functions all night after taking a hellish calc exam no more than 10 hours ago. I'm a wreck. Oh, and did I mention that my Stat final is at 10:20. Hmm, that like 4:20 from now. I'm sunk.
Overhauled the theme scripts last week.
Instead of the convoluted attribute style that we were using for themes before, it's now a simple one-to-one list of styles and theme attributes. I think I was making a false assumption before that a single style attribute would be used for many thing on a node, but the truth of the matter is that it's just not how it's worked out. One to one doesn't really sacrifice much in terms of "cleanliness", but it buys me tons of speed and the ability to now set themes and styles at the same time (and not incurr a huge parsing hit).
What does all that blathering mean? Well, in 0.2.3, you'll be using theme.setStyleByAttr(nodeRef, themeAttrName, styleName) all over the place, and you'll save yourself all kinds of trouble in the process.