Apologies for my low activity on this blog recently. I've been swamped during the NetBeans 6.1 development cycle.
now built on the same infrastructure as the Ruby editor. It's been quite a sprint to get it done, but we're
IDEs and editors.
Does this mean I've moved on from Ruby, and the NetBeans Ruby support is now in maintenance mode?
Far from it! Not only did we double the size of the NetBeans Ruby team from 6.0 (when Martin Krauskopf and myself
were the team); in 6.1 Erno Mononen and Peter Williams joined us. And I'm still in charge of and working on the
Ruby editor - which in 6.1 adds complete Rails 2.0 support (and Rails 2.1 - I just yesterday integrated support
for the new UTC timestamp migrations), as well as
a bunch of new quickfixes, and tasklist integration, etc.
However, a lot of the work I've been doing has been on the editing infrastructure, which benefits
Ruby directly. For example, in NetBeans 6.1, the long file indexing process which would happen on every IDE startup
now happens only on the first startup. And more importantly, we're much more robust now in handling complicated
embedding scenarios in ERb/RHTML files. Where in 6.0 we had a lot of custom code to handle ERb specifically,
automatically and correctly in ERb files as well. So features like mark occurrences and semantic highlighting
which were not available in 6.0 now work in ERb files as well for Ruby.
editing as well.
a Rails-focused introduction to some of the features.
First, let's create a new Rails project. Then I open the
First, take a look at the semantic highlighting. Prototype-style method definitions are bolded. As with Ruby, unused local variables, parameters and catch scope variables etc. will be detected and underlined. And NetBeans figures out the scope of variables and shows you global variables in a different color (green, but that is obviously configurable). This helps you find cases where you perhaps have a typo so instead of referencing a local variable, you're accidentally trying to read a nonexistent global variable. Or, as is the case in this screenshot, they were probably accidentally declaring a global variable:
I doubt that the intention for this function was to leak out a new variable named position; the intention was probably to have included a
var keyword here to make the loop variable local like this:
Let's move on to the quickfixes. Take a look at the vertical scrollbar on the right - here it is again (flipped horizontally) :
Each little yellow mark corresponds to a quickfix warning NetBeans has added at roughly that position in the source file. The tasklist view lists these such that you can sort by type. (This isn't some doctored up testcase file to exercise the quickfixes - this is the standard
Every quickfix type can be disabled - and they also offer links to more information about the error. Here's the warning for multiple return values:
The mark occurrences feature lists all the exit points of a function when you place the caret on top of the corresponding
function keyword. Here you can see that we have both a plain
return; with no return value, as well as another return with a value. How would a caller of this function treat the return value of this function?
There are a lot more detectors, which I will describe in a future blog post. Now, let's open the default
index.html file that ships with Rails. Here's code completion on the Prototype
As you can see, it uses the HTML parse information (this is part of the language infrastructure I talked about earlier) to locate all the element ids in the document and offers those as completion. As you can see it includes those ids that were accessed by Rails' own
$-calls for the lines above.
Code completion also works with the Prototype
$$() function, which performs CSS selections. First, show the used element types in the document:
Then filter on the HTML element classes in the document:
There's just one - from a few lines later:
We can also filter on the many CSS pseudo classes:
Here's a blog entry somebody
else wrote with some more features and screenshots. The main point of this blog entry was to explain why
is going to continue developing at rapid clip. Code editing is a top priority for NetBeans!