Archive for the ‘RSTALanguageSupport’ Category

JavaScript Language Support Updates

Monday, February 6th, 2012

First, a quick note that RSyntaxTextArea 2.0.0-beta3 is available on SourceForge!  Among other things, this release greatly improves syntax highlighting for JavaScript, HTML, PHP and JSP.

I promise RSTA won’t stay on this “beta” release track forever…

Anyway, there’s also been progress in the JavaScript language support.  It’s been in SVN for serveral days now, I just never got around to blogging about it.  Some of the “polish” I spoke of in my last post is now there:

JavaScript Improvements

JavaScript Improvements

Note the icons in the completion choices window and the outline tree on the left-hand side.  Clicking on an element in the outline tree selects that element in the editor, just like in the Java support.  We also now have Go To Member support:

Go to Member

Go to Member

Ctrl+Shift+O (Cmd+Shift+O on OS X) displays this popup allowing you to type/select the name of a variable or function to navigate to in the editor.

Here’s what’s coming up next with JS support:

  1. Take scoping into account when displaying completion choices.
  2. Use knowledge of variable types to provide better completion choices.
  3. Clean up JSDoc descriptions in the completion description window.

 

Minor updates

Saturday, January 28th, 2012

Nothing bad has been found with code folding yet – so far so good!  A few tweaks in other areas were pushed recently, the most important probably being a scanning bug in HTML and other web languages.  A JavaScript line comment (“// …”) should not hide a closing </script> tag.

If you’ve watched this blog for any length of time, you might have noticed that my motivation often shifts from one area of the project to another (new language highlighting, code completion, code folding, etc.).  Well, since code folding is winding down, I’m turning my focus back to code completion.  The wonderful Rhino project, along with more web programming at work, has motivated me to look into JavaScript code completion.

A few months ago, somebody emailed me stating that they were working on this very thing.  We were hoping to get his work integrated into RSTALanguageSupport at some point, but unfortunately I stopped hearing from him, and I can no longer find that email thread (!).  In any case, I decided to dig into this myself.  The good news is that Rhino has an incredibly easy-to-use API.  I literally read no documentation at all – just Ctrl+Space’d and picked out the classes it looked like I needed.  Fantastic!  In a short while I already had squiggle underlining of syntax errors and working completion for functions and variables:

JS Code Completion - Day 1

JS Code Completion - Day 1

It’ll look prettier when it’s done of course; this is without any polish.  This will be made just as robust as the current Java language support, but with full syntax checking (Java currently doesn’t check for syntax errors in method bodies).  This should include both an outline tree component as well as Go to Member support.

I should also hopefully get off my bum and get back to work on the Java support.  When I do, I’ll be picking up where I left off, improving parameter completion (determining variables in scope of the right type/subtype for a parameter and suggesting them).

Java: Go to Member

Monday, December 19th, 2011

One feature currently in the JavaLanguageSupport is “Go to Window”.  Pressing Ctrl+O (I know, needs a different shortcut) pops up a tool tip-ish window with a tree view of the members of the current source, just like in Eclipse:

Go to Member

Go to Member

At the top is a text field.  Typing in this field filters what members are visible in the popup on the fly:

Filtering while typing

Filtering while typing

Selecting a member in the window selects that member in the editor:

Making a selection

Making a selection

Once you start using this feature, you’ll never stop using it.  It’s much faster than manually scrolling through source code!

While only about 80% of the way there, this functionality will of course be broken apart from the Java language support in particular, so it can be used by other languages.  Unfortunately Java is the only one for which I’ve created a parser capable of finding the members in a source file.  I’ll probably move the ctags support from [url=http://fifesoft.com/rtext/]RText[/url] into RSTALanguageSupport just for this.

JSP Code Completion

Tuesday, July 19th, 2011

Some degree of JSP code completion is working its way into RSTALanguageSupport.  Currently only code completion/inline documentation for the standard JSP tags are baked in, but coming soon will be support for importing taglibs.  The code is actually mostly there; the problem is figuring out how to expose it in the API in a simple, clean way.  It’s a little tough since RSTA is just a text editor component; for an editor application with the concept of a project or workspace, things would be a little easier.

As with HTML code completion, only attributes appropriate for the tag at the caret position are suggested.

JSP Code Completion

JSP Code Completion

Java Code Completion Updates

Friday, June 24th, 2011

A couple of minor fixes to Java code completion support in RSTALanguageSupport have just been added:

1. Member completion for string literals has been added.  If you’re like me, and are a fan of putting String literals first in string comparisons, i.e.

   if ("PROPERTY_FOO".equals(value)) {
     // ...
   }

then you can see this feature in action.

String Literal Code Completion

String Literal Code Completion

2. Fixed a bug where, if multiple local variables of the same type were declared, and some initialized, in the same statement, some of them would not get parsed.  In the example below, “two” and “three” were not parsed previously, but now they are.

Multiple grouped local var declarations

Multiple grouped local var declarations

Many consider declaring variables like this to be poor form, but it’s valid syntax nonetheless, so the parser should handle it properly!

Generics support added to Java Code Completion

Sunday, January 23rd, 2011

Support for generics (added in Java 5) is something that was sorely lacking from the Java code completion in RSTALanguageSupport.  That is, until the latest Subversion changes!  This is a very early implementation, and like a lot of the recent Java support changes, there may be bugs and performance issues.  But it’s there!  And things look good for simple usage of the java.util Collecitons classes:

Generics Support

Generics Support

Previously, methods such as List#add() and List#get() would always say that their parameter/return types were of type Object.  Now, if you specify type arguments to classes that accept them, code completion will reflect those type arguments.

As before, please be bleeding edge, try this out, and report back bugs!  You can do so either here, or in the RSyntaxTextArea forums.  There is also currently no way to turn this feature off (i.e. if you want to program with “-source 1.4″ effectively enabled), but that will come soon.

More helpful Java code completion – Feedback please!

Wednesday, January 12th, 2011

If you’re using the JavaLanguageSupport in the RSTALanguageSupport trunk, I’d appreciate it if you checked out the latest and tried it out.  It has a nice new feature in that, if source is attached to jars on the classpath, code completion suggestions for methods will include the methods’ parameter names (assuming they can be found in Javadoc for the method):

Method param names in choices window

Method param names in choices window

Method param names in parameter assistance

Method param names in parameter assistance

Previously, parameter names were grepped out of the source file being edited’s methods, but for any compiled classes on the “classpath,” method parameters were identified by their type only.  The only way to know what each parameter was (short of having the API you’re using memorized) was to read the information in the description window.

Now, Java support has taken the next step.  It’s already reading the Javadoc for each method to put it into the description window, so why not grep the parameter names out of it, and use them everywhere else, such as the main code completion choices window?

If you point your application to a JDK, it’ll automatically locate the source zip (actually, it already did this). and this feature will work out-of-the-box!

My only concern is performance.  This is an un-optimized feature, and it does result in significantly more I/O (reading from the source zip or directory) than was done previously.  Memory consumption should be about the same, though there may be a lot more smaller temporary objects created (i.e. more GC).  So I request that if you grab the latest, you report back to me if there are any performance issues.

Have fun!

Yet More Java Code Completion Improvements

Saturday, December 18th, 2010

The fun never stops!  A couple more enhancements have been added to JavaLanguageSupport in the past few days.  Both of these are actually possible thanks to enhancements to the AutoComplete library, so you’ll need to update that too, but currently the Java code completion is the only thing that takes advantage of them.

First off, Java completion choices are now sorted by relevance, instead of alphabetically:

Sort by Relevance

Sort by Relevance

Note how the local variables and members are displayed before methods, which are both displayed before class names.  Previously everything was sorted purely alphabetically, putting the things you’re most likely to type (variables, fields and methods) in the middle of a huge amount of classes you’re less likely to want.

The next enhancement is completion suggestions for method parameters.  Now, not only do you get the nifty Eclipse-like parameter tool tip, parameter highlighting, and tab-to-move-between-params, you’ll also get a small popup listing all local variables, members, and getters whose types match (or are subtypes of) the type required for the currently-focused parameter!

Parameter choices completion

Parameter choices completion

Although in the example above there are only a small number of suggestions, note that again, the completions are sorted by relevance.  Also note that you’ll get “null” as a standard suggestion for non-primitive types, and “0″ as a standard suggestion for numeric primitive types.

Java Code Completion Improvements

Wednesday, December 8th, 2010

There have been some great improvements to the Java language support in RSTALanguageSupport.  If you haven’t looked at it lately, here’s what you’re missing out on:

1. Import statements are added when code completion inserts a class name that has not yet been imported.  Following in the footsteps of IDE’s such as Eclipse, this feature prevents you from having to manually enter all your import statements; just type away, and hit Ctrl+Space to have them added for you.  Thanks go out to users Guilherme and Jonatas for the initial implementation of this feature, and for making me get off my bum and start working again on the library!

Before...

Before…

... and after.

… and after.

2. Duplicate local variable names are squiggle-underlined and flagged as errors.  A small but useful check.

Duplicate local variables - syntax error

Duplicate local variables – syntax error

3. Fixed a bug, and now the code completion list correctly handles and shows multiple classes/interfaces with the same name, such as javax.swing.text.Document and org.w3c.dom.Document.  Previously only one such class would “win out” and be listed as a completion choice.  Now, they all have equal and fair representation!  Once again, the hard work was done by Guilherme and Jonatas.

Multiple classes/interfaces/enums with the same name

Multiple classes/interfaces/enums with the same name

If you haven’t done so yet, download the RSTALanguageSupport project from SVN and give it a try!

Big Source Browser improvements for Java

Sunday, November 14th, 2010

RText has almost always had a “Source Browser,” a panel docked on the left (by default) that gave an outline of the code in the currently active editor, similar to the “Outline” view in Eclipse.  This component is powered by ctags, either the standard one if you’re on *nix, or Exuberant Ctags on Windows (or again on *nix if configured that way).  Using the former buys you outlines for C source only, while using the latter gets you outlines for any programming language supported by both Exuberant Ctags and RText (really, what’s supported by RSyntaxTextArea).

But not too long ago, as part of my Language Support add-on library efforts, I also implemented an outline tree specifically for Java, almost perfectly mimicking Eclipse’s Outline view.  I’ve been wanting to use it in RText for awhile now, but figured since it was currently Java-specific (won’t display an outline for any other language), it couldn’t be used.  Well, I finally bit the bullet and made RText’s SourceBrowser “pluggable.”  Languages can register a specific tree view for themselves, but if they don’t, it falls back on the standard ctags-based tree.  This allows me to register and use the JavaOutlineTree class only when editing Java code.  Here’s a screenshot:

Java Outline Tree

Java Outline Tree

As you can see, the Source Browser now provides much more detailed, and much nicer looking, information for Java classes.