JSHint integration and more JS features in Language Support

February 7th, 2014

There are a few handy new features coming for JavaScript developers in RSTALanguageSupport.

Probably the coolest feature is JSHint integration.  By default, the JS support uses Rhino to provide syntax checking, code completion, and an outline tree view of code.  This continues to be the case, but you can now configure RSTA to use JSHint for syntax checking (code completion and outline views are still handled via the AST created by Rhino).  To do this, you can use the following new methods in the JavaScriptLanguageSupport class:

LanguageSupportFactory lsf = LanguageSupportFactory.get();
JavaScriptLanguageSupport jspf = (JavaScriptLanguageSupport)lsf.getSupportFor(SyntaxConstants.SYNTAX_STYLE_JAVASCRIPT);
jspf.setJsHintRCFile(new File("path/to/.jshintrc")); // This is optional

JsErrorParser is a simple enum that allows you to toggle between Rhino and JSHint for error checking.  Once JSHint is enabled, you can optionally point to a .jshintrc file to dictate what errors/warnings should be flagged.  If you don’t do this, JSHint’s defaults are used, but doing so allows you to fully tailor your JS editing experience.

Here’s an example screenshot showing some warnings and errors identified by JSHint, some of which aren’t caught by Rhino:

JSHint Warnings

JSHint Warnings

A word of caution:  currently, the JSHint parser is executed on the EDT.  This means there could be performance issues (most likely just a short pause when the code is re-parsed).  In the next release I plan on rejiggering the RSTA parsing API so such things can be done off the EDT.  But for typical JavaScript files (under a couple of thousand lines) the pause is pretty negligible, and you can always switch back to Rhino in the short term if it is an issue.

Next, the JS outline tree now recognizes JavaScript “classes” built by extending a prototype:

Prototype Support

Prototype Support

This is the first step in making the Outline Tree for JavaScript code smarter and smarter.

Finally, the current function scope of the caret position in a JavaScript file is now outlined in the gutter, similar to what is done for Java.  This is just a small but useful visual cue as to what scope you’re currently working on in the file:

Current Scope in the Gutter

Current Scope in the Gutter

Hopefully the next RSTA/AutoComplete/LanguageSupport release will be in the next couple of weeks.  Look for it soon!

CSS Code Completion

December 24th, 2013

Code completion for CSS files has been added to RSTALanguageSupport.  Icons were graciously borrowed from Eclipse (as usual).

You get code completion for at-rules and HTML tags for selectors:

at-rules and HTML tags

at-rules and HTML tags

As well as property names:

Property Completions

Property Completions

And for certain properties, you’ll also get code completion for their values:

Value Completions

Value Completions

By default, the completion popup is automatically triggered (after a delay) when typing the “@” character for at-rules, and when typing ‘:’ or a space after a property name.  As always, this is configurable.

Moving forward, short documentation for each CSS property (and values too!) would be awesome.  If anyone has time or motivation and wants to contribute, pull requests or patches are welcome!

RSyntaxTextArea and RText 2.5.1 released!

November 13th, 2013

Both RSyntaxTextArea (and its sister projects) and RText have brand new 2.5.1 releases available on GitHub and SourceForge!  The RSTA updates fixed a couple of bugs that had crept into the library in the 2.5.0 release.  RText (which hasn’t seen an update in a few months) is now using the latest, greatest RSTA libraries, which also means it’s using the slick new search toolbars I blogged about previously.

Check ’em out!

Search API Updates

September 22nd, 2013

The next release of RSyntaxTextArea and RSTAUI will feature some enhancements to the Search API.

Find and Replace operations were always done through the SearchEngine class.  This class contained the following static methods:

   public static boolean find(JTextArea textArea, SearchContext context)
   public static boolean replace(RTextArea textArea, SearchContext context)
   public static int replaceAll(RTextArea textArea, SearchContext context)

The find() and replace() methods returned whether a match was found/replaced, and the replaceAll() method returned the number of replacements performed.

In order to do a “mark all”, you had to call a method on an RTextArea instance:

   public int markAll(String toMark, boolean matchCase, boolean wholeWord, boolean regex)
   public void clearMarkAllHighlights()

In the next release of RSTA, the “mark all” API will be moved into SearchEngine, so that it is a one-stop shop for everything related to search. Further, these methods will return a new SearchResult object, containing more uniform, detailed information on the result of the operation.

The find() and replace() methods will now check context.getMarkAll(), and if it returns true, they will automatically perform a “mark all” operation along with the find/replace requested. This is very useful because often, people want to visually see what other matches are nearby the one actually found and selected.

The search-related components in RSTAUI have been updated as well. Besides the existing Find and Replace dialogs, there are now two new components – FindToolBar and ReplaceToolBar. When wrapped in a CollapsibleSectionPanel, these tool bars can provide a search UI integrated into an application’s main window, as opposed to the standard approach of modal dialogs. This is the trendy new way of doing things. In addition, these components use an animation to “slide” in and out of the UI, breathing a little bit of life into a Swing application.

Below is an example of setting up a window where Ctrl+F and Ctrl+H will bring up a FindToolBar and ReplaceToolBar, respectively:

   JPanel contentPane = new JPanel(new BorderLayout());
   JMenuBar mb = new JMenuBar();
   JMenu menu = new JMenu("Search");
   // Create our search tool bars and tie their search contexts together.
   findToolBar = new FindToolBar(this);
   replaceToolBar = new ReplaceToolBar(this);
   // Add our search tool bars to the "collapsible section panel."
   // Ctrl+F and Ctrl+H will display these tool bars. Use the returned actions to
   // create menu items for our application menu bar.
   CollapsibleSectionPanel csp = new CollapsibleSectionPanel();
   int ctrl = getToolkit().getMenuShortcutKeyMask();
   KeyStroke ks = KeyStroke.getKeyStroke(KeyEvent.VK_F, ctrl);
   Action a = csp.addBottomComponent(ks, findToolBar);
   a.putValue(Action.NAME, "Find...");
   menu.add(new JMenuItem(a));
   ks = KeyStroke.getKeyStroke(KeyEvent.VK_H, ctrl);
   a = csp.addBottomComponent(ks, replaceToolBar);
   a.putValue(Action.NAME, "Replace...");
   menu.add(new JMenuItem(a));

Here’s an example of what the tool bars look like:


Find Tool Bar

Find Tool Bar

Replace Tool Bar

Replace Tool Bar

Ctrl+F/Ctrl+H toggles between them, and Escape hides the currently visible one, if any.  If “Mark All” is enabled, all matches are selected in the editor as you type, which is a very nice feature.  The “mark all” event waits for a short time after you stop typing before it fires (defaulting to 200 ms).  That way, it doesn’t perform a mark-all operation for each letter you type if you type really quickly.

Just like the older Find and Replace dialogs, the Find and Replace tool bars will offer code completion for regular expressions:


Regex assistance

Regex assistance

This code is already pushed to GitHub; all I have left to do is some more testing.  I also plan on improving the performance of “mark all;” it’s slower than the “mark occurrences” support in RSTA and there’s no reason for that.  And since these new components make it so easy and handy to have “mark all” enabled all the time, I figured I’d go ahead and knock that out sooner rather than later.

RSyntaxTextArea 2.5.0 Released!

August 26th, 2013

RSyntaxTextArea 2.5.0 was just released on GitHub!  The sister libraries AutoComplete, SpellChecker, RSTAUI were updated as well.  Here’s what’s new:

  • The minimum required JRE for the libraries was bumped up to Java 5 from 1.4.  There was no hard requirement for this from a feature point of view, but it allows us to fix a few issues here and there, and modernize the code base, which is a boon for developers.
  • Improvements in both the painting code and syntax parsing code.
  • Added syntax highlighting and code folding for .htaccess files.
  • Bug fixes in JavaScript and Clojure syntax highlighting.
  • The source repositories were (obviously) moved from the old SVN repositories hosted here on fifesoft.com to GitHub.
  • A few other minor changes.

Check it out and let me know what you think!

RSyntaxTextArea repositories now on GitHub, require Java 5

August 11th, 2013

Two big things going on with RSyntaxTextArea!

First, the source for RSTA ia being moved from our personal SVN server to GitHub.  Since GitHub is the place to host open source projects these days, hopefully this new home will provide RSTA with more exposure and accessibility.  AutoComplete, SpellChecker, and the other sister libraries are moving over as well.  I haven’t quite decided yet what will happen to the current SVN server; my current idea is to keep it up and available, but to edit the readme files and Ant scripts to talk about the new location (and not actually build anything in the case of the Ant scripts, to force people to notice!).  But I can’t decide whether it’s better to just remove the repository entirely – that will force users to see it’s no longer there, causing them to go to the site and realize the source is now on Github.  While it’s a little more harsh, it will keep the project from appearing “dead” to people who simply monitor the SVN and see no updates being made.

The second big change is that, starting with the next release, RSyntaxTextArea will require Java 5.  Yes, I’m finally retiring support for Java 1.4.  If you still need to run on such an ancient JVM, you can continue to use 2.0.7 (or even fork it on Github!).  If any huge issues are found I’ll be happy to create a maintenance branch based off 2.0.7 for you Java 1.4 folks, but I seriously doubt that’ll happen.

Migrating to Java 5 doesn’t do much for the library itself, but it does modernize the code base, and fixes a couple of odd issues here and there.  You’ll find “java5” branches in each RSTA project now; that’s where all the action is.  I’m trying to embrace git’s painless branching and all.  🙂  When the work is finally done (should be in a day or two) I’ll merge these branches back into master.

Finally, I’ll be adding all known issues into the GitHub issue tracker and any other bits and pieces left remaining.  As an aside, I’ve found GitHub’s interface to be painless, fast, and intuitive.  Much better than the clunky old SourceForge interface.

.htaccess file support

July 14th, 2013

The upcoming release of RSyntaxTextArea will support syntax highlighting and code folding for .htaccess files.  This was just added in SVN commit 814.

htaccess Support

htaccess Support

RSyntaxTextArea and Java 1.4 Support

June 23rd, 2013

Does anybody really need Java 1.4 support anymore?  RSTA is one of the few remaining, active Swing libraries that supports this ancient version of Java.  It reached its EOL in 2008 (almost 5 years ago!), and even its extended support ended in February 2013.  Being a syntax highlighting text component, there hasn’t really been anything added to the JDK from Java 5 onward that would benefit it, so I’ve been keeping its minimum JRE version back at 1.4, just to keep it as “compatible” as possible.  However, there are a few drawbacks because of this:

  1. There is one API change in the JDK that occurred between Java 1.4.2 and 1.5 that affects RSTA.  The code in the repository builds cleanly when built with a true 1.4 JDK, but you will receive an error for XmlParser.java when building with Java 5+ (even if you set -source 1.4).  When building RSTA with the included Ant build scripts, you will get a big fat explanation of this spit to stdout, so you know rectify the situation if it happens to you (just add a throws-clause to a single method), but Java novices may not fully understand what’s not working.  Moving the bar up to 1.5 will clean this issue up entirely.
  2. For JavaScript code completion, RSTALanguageSupport has a dependency on Mozilla Rhino, which is developed with Java 5 but offers a 1.4-supporting version, I believe using Retroweaver.  While this is fine and dandy, and everything works, a future version of Rhino may well not include a pre-built 1.4-compliant Rhino jar, and I certainly don’t want to be in the business of building and supporting it myself.  It would be a little nicer if this nuance weren’t there.
  3. One area where the JDK does offer nice new functionality for an editor like RSTA is XML parsing.  We could add schema-based squiggle underline validation to XML files.
  4. It would be a little nice to modernize the code base.

If anyone feels strongly that we should keep releasing pre-built versions of RSTA that run on Java 1.4, please let me know, preferably in the forums.

RSyntaxTextArea – Plans for Next Release

June 9th, 2013

Because I haven’t had much time to work on RSTA lately, I’ve been thinking about making a list of work items in an attempt to get motivated.  So here’s what’s on the list so far for the next RSTA release:

  • Performance improvements, particularly for word wrap with very long lines.  This has been asked for a couple of times in the forums.  I’ve done some work, that will be available in the next SVN commit, that will improve performance to some degree.  One of RSTA’s primary issues here is that modelToView()/viewToModel() calculations are relatively expensive, and for very long word-wrapped lines, they are called literally dozens of times whenever text is inserted or the window is resized.  As a first pass, I’m refactoring things a bit so that the data used by these method calls is cached much more aggressively; this seems to improve things quite nicely.  Moving forward, I might also try to minimize the number of calls to these methods in general, though that will be a more difficult task.  There were also some performance improvements made to WrappedLineView.java in the JDK, around the Java 5 timeframe, that RSTA may be able to learn from/graciously borrow.
  • Syntax highlighting for R.
  • Syntax highlighting for .htaccess files.
  • API in AutoComplete libarary to specify the expected type of arguments in a parameterized completion.

Any other suggestions?

RSyntaxTextArea Developer Documentation Started

May 8th, 2013

Have you ever been interested in integrating syntax highlighting for your own, custom language into RSyntaxTextArea?  Now there’s finally a guide to help you do just that!


This “developers documentation” section describes in detail how syntax highlighting is implemented in RSTA, and multiple ways that you can add your own.  In the future, it’ll have similar documentation on adding code folding, code folding, and squiggle-underline parsing.

Feedback is welcome!