Archive for the ‘RSyntaxTextArea’ Category

setBracketMatchingEnabled(boolean) now checks for brackets “to the right” of the caret if one is not found “to the left.”

Added API for applications to create custom hyperlinks in RSyntaxTextArea, though this API should not be considered stable.

Added “mark occurrences” support for XML. Currently just highlights the tag name at the current caret position and its match.

Fixed issue when auto-inserting spaces for tabs.

Major refactoring of rendering code.

“Traditional” selection rendering is now supported; that is, selected text can now be rendered as syntax highlighted tokens with a “selection” background (as it was previously), or as text as a single color with the “selection” background (as standard text components do). See RSyntaxTextArea.setUseSelectedTextColor(boolean).

Fixed performance issue in FoldingAwareIconRowHeader when it paints “active regions.”

Added some new token types to better differentiate markup tokens from “regular” language tokens. This allows for better syntax highlighting for stuff like HTML, JSP, and PHP.

In RSTAUI, a new TextFilePropertiesDialog was added. This dialog shows the currently edited text file’s path, size, word count, encoding, line terminator, and more. Further, when using a TextEditorPane, you can modify the file’s encoding or line terminator directly from the dialog.

RSTALanguageSupport: JavaScript code completion now offers suggestions for JSDoc when in documentation comments.

RSTALanguageSupport: HTML, PHP, JSP and XML now have an option to automatically add closing tags when opening tags are typed (e.g. add “</foo>” when “<foo>” is typed). By default this option is enabled. HTML, PHP and JSP only auto-close tags closeable in the HTML 5 spec; XML closes all tags. This option is separate from the XML “auto-complete closing tag name when ‘</’ is typed” option.

Below are a couple of screenshots showing off the new JSDoc syntax highlighting and code completion. The first one shows auto-completion kicking in after typing “@” in a documentation comment. The second screenshot shows the parameterized assistance you get for “@param”:

Syntax highlighting for Visual Basic was just added into SVN. I probably won’t bother with code folding support for VB any time soon, since I don’t ever write code in it, but if you’re itching to contribute, I’m always willing to take patches!

Note that all of these are related to markup languages, such as XML, HTML, JSP and PHP. Previously, the lexers for each of these languages identified and colorized all of these constructs, but re-used token styles for other token types when rendering them. For example, entity references were previously rendered using the “variable” token style. This wasn’t optimal, as it meant that theme designers had to be aware of this token-style re-use when creating custom Themes, if they wanted their Themes to be as pretty as possible. Not so any longer!

Another new feature is that RSyntaxTextArea now supports the standard editor behavior of selected text using a different font color than unselected text. Previously, selected text always still rendered using the proper syntax highlighting styles. Now, this is configurable via the setUseSelectedTextColor(boolean)/getUseSelectedTextColor() API. Theme XML can also specify how a theme wants this property set. Below is a screenshot that compare the “dark” default theme, which has this property set to false, and the “eclipse” default theme, which has this property set to true:

Selected Text Rendering

Themes can also now use a special value “default” for selection foreground and background colors, which means “use the LookAndFeel’s (not system’s!) default for these values). Check out the theme DTD for specifics.

These changes do unfortunately mean that themes created for older RSyntaxTextArea versions will no longer work with (the upcoming) 2.0.7+, as they will not pass validation against the DTD. They can be easily updated however, so I don’t see this as much of an issue.

Finally, all of the sample themes have been updated to use the new features above. Also, a new sample theme was added to the mix: idea! Thanks to Mikle Garin for this theme. This is obviously based off of IntelliJ IDEA‘s default theme.

IDEA Theme

Who knows, maybe a theme based off of its new Darcula will show up next.

Posted in RSyntaxTextArea | Comments Off on Improved Syntax Highlighting and Theming Support

Further, the AutoComplete and RSTALanguageSupport libraries now look good in Substance (in particular, Insubstantial). Previously, these libraries used DefaultListCellRenderer for their completion choices. Substance, being the barrel of fun that it is, forces libraries to extend its own DefaultSubstanceListCellRenderer, otherwise they aren’t rendered with Substance’s striping, gradients and rollover effects. Now, RSTA and its cousins detect when Substance is the current Look and Feel, and render with a DefaultSubstanceListCellRenderer when necessary. Easy peasy!

Substance in AutoComplete Popups

(Pardon the fact that I didn’t update the editor color scheme to be dark as well!). This is done via reflection, so there is still no build dependency on Substance. This of course assumes that the DefaultSubstanceListCellRenderer class name and package don’t change in future releases of Insubstantial, but I highly doubt that’ll happen, considering it’s a maintenance fork of the original Substance. And if something goes horribly wrong, the library should fall back into its default rendering path anyway.

The outline trees (JavaOutlineTree, XmlOutlineTree, etc.) still use DefaultTreeCellRenderer, but applications can use the same technique here – wrap the standard renderers for these components with SubstanceDefaultTreeCellRenderer, call delegate.getTreeCellRendererComponent(), then set the Substance renderer’s icon and text based on the delegate’s values. Come to think of it, I’m not sure why I didn’t have the libraries automatically delegate like I did with the completion choices lists… maybe next release. One thing you do lose from this delegation is the rollover effect – the render “looks” the same, but the animated rollover effect depends on the actual renderer being a DefaultSubstance*Renderer. Since we’re only *delegating* to one, we’ll look like it, but won’t get the rollover effect.

RSyntaxTextArea 2.0.5.1 was just released on SourceForge! This release fixes the problem with typing the ‘/’ character on non-QWERTY keyboards, so is a must-upgrade if you’re using 2.0.5 (2.0.4 did not have this bug). It also updates the Arabic translation (thanks Mawaheb!).

The AutoComplete, SpellChecker, and RSTAUI add-on libraries were also updated with Arabic translation updates.

HTML and PHP finally got code folding added! The current implementation only adds fold regions for tags that require being closed. Inline JavaScript and PHP code are not currently checked for fold regions. JSP will likely soon follow.

HTML Code Folding

Also, support for NSIS scripts has been added. I’m sure most developers are familiar with NSIS, which makes it super easy to create installers for your Windows applications. RSTA now supports full syntax highlighting and code folding for NSIS scripts:

I usually don’t do such quick follow-up releases, but 2.0.4 introduced a font rendering bug that caused many Asian fonts to not be rendered properly out-of-the-box (at least on Windows). This has been corrected in release 2.0.4.1 on SourceForge. If your product has non-English speaking users it’s probably a good idea to upgrade to this release.

Posted in RSyntaxTextArea | Comments Off on RSyntaxTextArea 2.0.4.1 Released

RSyntaxTextArea 2.0.4 was just released! Grab it either from SourceForge or SVN (see also web viewer, javadoc). This release updates RSTA as well as the sister projects AutoComplete, RSTALanguageSupport, and SpellChecker, and adds yet another sister project: RSTAUI! Here’s the complete list of what’s new:

Just pushed to SVN, whenever you move the caret over a bracket, you now have the ability to highlight both brackets, not just the matched one. Some folks find this useful, as the bracket at the caret position will not highlight if they forgot to insert the closing bracket, for example. It can also be useful to visually identify the scope of a code block.

Matching both brackets

To further help with scope identification, I hope to implement a standard range painter for the gutter, for C-style languages that use curly braces to denote code blocks. This range painter would highlight the deepest code block of the caret as you moved around the code. The basic API for this already exists, and in fact, the Java language support in RSTALanguageSupport uses it to highlight the method the caret is in (if any). But it would be nice if there was a more generic one for C, JavaScript, C#, etc.