Archive for the ‘RSyntaxTextArea’ Category

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.

 

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).

RSyntaxTextArea 2.0.0-beta2 Released

Saturday, January 14th, 2012

The second beta of 2.0 was just released on SourceForge.  This beta makes folding work when word wrap is enabled, fixes some keyboard shortcuts that didn’t work quite right around folded regions, and a few other minor things.  Check it out!

There are a few more things I’d like to do before a final 2.0 release, but they’re pretty minor.  The battle plan includes:

  • Folding should recognize XML comments.
  • API to do find/replace in selection (not just next/previous from caret or all).
  • A couple of more token types (again).
  • A way for users to disable the fold indicator tool tips for collapsed fold regions.
  • Profile performance of common operations when code folding is enabled, make sure there aren’t horrible degradations caused by the code folding code.

As always, please please please start using code folding ASAP and let me know of any issues you find!