Archive for the ‘RSyntaxTextArea’ Category

RSyntaxTextArea 2.0.4.1 Released

Friday, September 7th, 2012

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.

RSyntaxTextArea 2.0.4 Released

Sunday, September 2nd, 2012

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:

All:

  • Updated translations:  Chinese (peter_barnes), Russian (Nadiya), Polish (Chris), Spanish (Leonardo), Brazilian Portuguese (Pat), and Korean (Changkyoon).
  • Removed superfluous build warnings from projects when building with Ant 1.8+ (includeantruntime).

RSyntaxTextArea:

  • HTML, JSP, and PHP syntax highlighting now also highlight embedded CSS.
  • Background color highlighting for “secondary” languages (such as CSS and JS in HTML, JSP, and PHP).
  • Added code folding for Lisp and Clojure.
  • Minor Clojure syntax highlighting updates.
  • Changed default font to Consolas on Windows Vista and 7.
  • Decreased memory usage required for regex find and replace operations.
  • Improved performance of Mark Occurrences, especially when there are lots and lots of marked occurrences.
  • Added E4X highlighting to JavaScriptTokenMaker (can toggle on and off via a static property).
  • Added a property so that, when bracket matching is enabled, you can choose to have both brackets highlighted instead of just the “opposite” one.
  • Fix to RTextScrollPane class to facilitate using it in the NetBeans GUI designer.
  • Fixed misaligned icons in row header when code folding is enabled.
  • Fixed bug: FoldManager incorrectly auto-expanded deeply-nested folds for some edits that did not affect those folds.
  • Fixed bug: wrong initial width of line number margin when calling Gutter#setLineNumberingStartIndex(int).
  • GoToMemberWindow: Fixed occasional NPE.
  • TextEditorPane: Fixed bug: clear undo stack and dirty state when “loading” a new file.
  • TextEditorPane: Now automatically scrolls to top of file on load().
  • Fixed bug: NPE in DumbCompleteWordAction in some circumstances (whitespace at beginning of file).
  • TokenMakerFactory now allows user-defined TokenMakers to be loaded via different ClassLoaders.

AutoComplete:

  • Added template completions.  You can now create completions for constructs that have arbitrary structure and take any number of parameters, such as for-loops and other common boilerplate code.
  • Fixed memory leak when uninstalling AutoCompletes from text areas.

RSTALanguageSupport:

  • Tremendous updates to JavaScript code completion and syntax checking, all done by steve.  We now use Rhino 1.7R4 for parsing.  JS is now by far the best-supported language in RSTALanguageSupport.
  • JavaLanguageSupport: Much better display of Javadoc links in Javadoc completion popup.

RSTAUI:

  • New (optional) library providing fully functional, localized dialogs for Find and Replace operations in RSyntaxTextArea.  Supports searching forward and backward, regex searching, match case, mark all, and replace all.  The actual search operations are delegated to the RSTA library’s built-in SearchEngine class.
  • More common dialogs will be added to this library in the next release.  More information about this in a future blog post!

Bracket Matching Improvements

Tuesday, August 21st, 2012

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

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.

Scope Highlighting in the Gutter with Java Language Support

Scope Highlighting in the Gutter with Java Language Support

Secondary Language Highlighting, CSS in web languages

Wednesday, July 11th, 2012

Two improvements have recently been pushed to RSTA.  First, inline CSS is highlighted in HTML, PHP, and JSP files.  Previously, inline CSS was rendered as plain text; now it’s rendered just as if CSS highlighting were enabled.

Secondary Language Highlighting

CSS Highlighting in an HTML document

These days, TokenMakers for web-based languages are each actually highlighting several languages – JavaScript, CSS, HTML, and possibly JSP/PHP.  This means in documents with lots of inline scripts and styles, it’s not immediately obvious with a visual scan what you’re looking at with syntax highlighting alone.  Which brings me to the second new feature – secondary language highlighting.  When enabled, this allows TokenMakers to specify Tokens as belonging to specific “secondary” languages.  When secondary language highlighting is enabled, such Tokens are painted with a special background color.  This results in regions of code such as JavaScript and CSS blocks to be painted with a different background, as seen in the screenshot above.  It can be extra useful when viewing generated HTML with poor formatting:

Secondary Language Highlighting 2

Secondary Language Highlighting – JS and CSS in HTML

The bad news is, this feature comes at a fair performance penalty (since the background is painted for each individual Token, not for the entire region at once).  On good hardware (especially Windows machines) this shouldn’t really be a problem, but for this reason, this feature is disabled by default.  To enable and query it, use these methods in the RSyntaxTextArea class:

public boolean getHighlightSecondaryLanguages();
public void setHighlightSecondaryLanguages(boolean highlight);
public int getSecondaryLanguageCount();
public Color getSecondaryLanguageBackground(int index);
public void setSecondaryLanguageBackground(int index, Color color);

There are currently three secondary language backgrounds, which I’m assuming is a sufficient and practical number until someone proves otherwise.  :)  The Theme DTD and API have been updated so that themes specify the background colors for secondary languages as well.

Template Completions

Saturday, June 30th, 2012

A new feature has been added to the AutoComplete library trunk, and will be in 2.0.4 when it’s released:  template completions.  Equivalent to JDT’s editor templates in Eclipse, templates are an easy way to insert (usually, but not required) parameterized code into RSTA.

A common use case for TemplateCompletions is for inserting boilerplate code.  Take for example a for-loop that iterates through an array in Java.  The code always has the following structure:

   for (int i = 0; i < array.length; i++) {
    <cursor>
   }

The only thing that changes (sans formatting) is the name of the index variable and the name of the array being iterated through.  The ending cursor position should be inside the curly braces so the user can insert code into the looped-over code block.  TemplateCompletions provide a simple syntax for creating a code completion choice for inserting such a construct:

   String template =
      "for (int ${i} = 0; ${i} < ${array}.length; ${i}++) {\n\t${cursor}\n}";
   Completion tc = new TemplateCompletion(this, "for", "for-loop", template);

As you can see, a TemplateComletion takes a String representation of the code to be inserted.  Parameters are represented by substrings with the format “${foo}”.  These parameters are replaced by the user, similar to parameters in FunctionCompletions.  For parameters listed more than once in a template, only the first one can be edited by the user; during editing, all subsequent parameters with the same name will be automatically replaced with whatever the user types.

Parameters are cycled through via pressing Tab and Shift+Tab, or just by using the arrow keys.

The special parameter “${cursor}” denotes where the cursor will be placed upon pressing Enter or otherwise exiting template completion mode.  Specifying more than one ${cursor} in a single template results in undefined behavior.

Here’s an example of the above template actually being used:

Selecting the TemplateCompletion

Selecting the TemplateCompletion

Upon selecting the for-loop TemplateCompletion:

Inserting a TemplateCompletion

Inserting a TemplateCompletion

Editing the first “${i}” parameter:

Editing parameters

Editing parameters

Tabbing to (or pressing Enter to move directly to) the cursor end position:

End cursor position

End cursor position

All of the colors involved in marking parameters, etc. are configurable by the new org.fife.ui.autocomplete.AutoCompletionStyleContext class.

What’s next for this feature?  Well, again following in the footsteps of Eclipse, you should be able to specify the “data type” associated with each parameter, if any.  The AutoComplete library could then use that information to present the user with parameterized completion suggestions as it currently does for FunctionCompletions.

 

 

RSyntaxTextArea 2.0.3 Released

Tuesday, May 1st, 2012

RSyntaxTextArea 2.0.3 was just released on SourceForge!  Here’s what’s new:

 

  • LaTeX syntax highlighting and code folding:

    LaTeX Support

    LaTeX Support

  • DTD syntax highlighting:

    DTD Highlighting

    DTD Highlighting

  • Fixed an issue with RTextScrollPane, allowing it to be used in NetBeans’s visual editor
  • Fixed a bug in cold folding under certain cirumstances
  • RSTA now has anti-aliasing enabled by default (previously you had to call setAntiAliasEnabled(true) yourself)
  • TextEditorPane now fires FULL_PATH_PROPERTY from its load() method like it does from saveAs().

Download it today!

RSyntaxTextArea & RText updated in Maven

Thursday, April 19th, 2012

Just a quick note that a user has kindly updated the RSyntaxTextArea and RText artifacts available in Maven:

http://search.maven.org/#search|ga|1|g%3A%22com.fifesoft%22%20OR%20g%3A%22com.fifesoft.rtext%22

As usual, please report any issues in the forums.

RSyntaxTextArea 2.0.2 Released

Wednesday, March 14th, 2012

RSyntaxTextArea 2.0.2 was released yesterday on SourceForge!  This release includes some good bug fixes, and is recommended for anyone ready and willing to upgrade.  Here are the highlights:

  • The license was changed from LGPL to modified BSD.  There are folks afraid of anything with “GPL” in the title, perhaps rightfully so, so now RSTA is using a non-viral license.  This also clears up any confusion about a user’s ability to use a modified version of the library.
  • Added a cool new keyboard shortcut: select some text, and pressing Ctrl+K/Ctrl+Shift+K (Cmd on OS X) is “go to occurrence” like in Eclipse.  A quick and easy way to traverse through all instances of specific text in the editor.
  • Ctrl+/ inserts line comments when editing JavaScript, to match the “insert line comment” action in many other languages.
  • Fixed performance issue: Pressing “End” to go to the end of a very long line (thousands of characters) is no longer slow.
  • Fixed bug: Icon row header should automatically move icons around when folds are expanded and collapsed.  This is very important for folks looking to implement custom Parsers that show error markers in the Gutter, for example.
  • Fixed bug: When going to a bookmark via Ctrl+F2/Ctrl+ShiftF2, we should ensure that any collapsed folds enclosing the bookmark are opened.  Previously, the caret would be moved to the line containing the next bookmark, even if it was in a collapsed fold.
  • Other small tweaks.

As mentioned, the RSyntaxTextArea, AutoComplete, and RSTALanguageSupport libraries are all under a modified BSD license now.  The SpellChecker add-on library had to stay LGPL due to its dependency on a modified version of Jazzy.  I don’t see this as a huge problem since folks using SpellChecker aren’t as likely to want to modify it as they would with say the main RSyntaxTextArea project.

Enjoy!

RSyntaxTextArea 2.0.1 Released

Sunday, February 19th, 2012

All “.0″ releases have an obligatory follow-up maintenance release.  Grab RSyntaxTextArea 2.0.1 from SourceForge or Subversion today!  This release fixes the two following things:

  1. If SearchEngine selects text as part of a search/replace operation, and that text in a collapsed fold, the fold should be expanded to make the selection visible.
  2. The DTD for themes, theme.dtd, was not included in the 2.0.0 RSyntaxTextArea binary jar.  This made themes (one of the new features!) unusable since they could not be validated.

In addition, I made an API change.  I know it’s somewhat taboo to do that for minor releases, but it’s a straightforward change in your code to stay up to date.  This change is being made to support enhancements to the find/replace functionality in RSTA moving forward.

Previously, to do a find or replace operation in RSyntaxTextArea, you used one of the following methods from the SearchEngine class:

SearchEngine.find(JTextArea textArea, String text, boolean forward, boolean matchCase, boolean wholeWord, boolean regex);
SearchEngine.replace(JTextArea textArea, String toFind, String replaceWith, boolean forward, boolean matchCase, boolean wholeWord, boolean regex);
SearchEngine.replaceAll(JTextArea textArea, String toFind, String replaceWith, boolean matchCase, boolean wholeWord, boolean regex);

This is functional, but messy, and adding new options in the future would simply make the method signatures even longer (or introduce overloads).  To remedy this, I took a sip of the OO-KoolAid, and created a new SearchContext class.  This class keeps track of all information relevant to a find/replace operation.  The SearchEngine methods above now take a SearchContext instance as a parameter:

SearchEngine.find(JTextArea textArea, SearchContext context);
SearchEngine.replace(JTextArea textArea, SearchContext context);
SearchEngine.replaceAll(JTextArea textArea, SearchContext context);

This allows the searching API to stay clean, and adding support for a new search option is as easy as adding a new property to the SearchContext bean.  I hope to add support for at least two new search options in the future:  “search in selection” and “ignore comments.”

The actual SearchEngine class will likely be simplified as well.  Currently, it takes a different code path if you do a regex search than when you do a plain text search.  More code => more chances for bugs.  I’ll likely convert the plain text scenario into a regex one under the covers (convert your “find” text to a regex by escaping characters special for regular expressions).  This, along with making RSyntaxDocument a CharSequence, will greatly simplify the searching code, as well as provide a performance boost when searching large files.  All of this is implementation details of course, and won’t matter to someone just using the library.

Only RSyntaxTextArea has a 2.0.1 release.  AutoComplete, SpellChecker, etc. are still at 2.0.0 as they did not need any modifications.

RSyntaxTextArea 2.0.0 (final!) Released

Monday, February 13th, 2012

Enough with the betas!  RSyntaxTextArea 2.0.0 was finally released yesterday.  Folding appears stable enough and performance is good.  Editing a 400,000 line Java file with folding enabled does exhibit some delay while typing, but none while painting/scrolling – good enough for me!

Moving forward, focus will be shifted once again to code completion and RSTALanguageSupport.  JavaScript and Java completion both have work that needs to be done.  CSS highlighting also needs a little work (I never realized how complex CSS really is.  I’ve also had requests for “search in selection” and a few other miscellaneous features.  Any more suggestions for 2.0.1?  Post a reply here or in the forum!

The online Javadoc has been updated, and I’ll update the examples next.