Archive for the ‘RSyntaxTextArea’ Category

RSyntaxTextArea 2.0.0-beta1 Released

Saturday, December 24th, 2011

As I know that some folks aren’t too keen on always grabbing bleeding edge code from Subversion, I decided to make a “beta” release of RSyntaxTextArea 2.0 available on SourceForge as well as tagged in SVN.   I hope that releasing in jar form will help facilitate more folks using it and providing feedback.

Just as a recap, the major changes in this release currently include:

  1. Code folding for C, Java, Perl, XML, MXML, and other languages (currently only available when word wrap is not enabled).
  2. Theming support via XML.  This allows for easily customizing RSTA to fit the color scheme of your application, easier saving/loading user-defined token styles, etc.
  3. A few new token types to allow for better lexing/token highlighting.
  4. Updated syntax highlighting for some languages, especially PHP and JSP (which both previously had a couple of issues with JavaScript highlighting).

I’d like to make another call to action here, and ask everyone interested to try out the code folding support in their applications today!  Assuming you’re editing a language that supports it, it should be as simple as this:

textArea.setCodeFoldingEnabled(true);

The demo application in SVN provides a concrete example of this option in use.

Please report any and all problems you find in the RSTA forums!

Finally, I’d like to mention that I’ve gotten several emails that included patches with new features lately.  If you’re one of those folks, I’d just like to let you know that I am interested in what you’ve sent, I just haven’t yet gotten around to looking at it and working it in if/where possible.  Feel free to email me again if you want, but even if you don’t , I’ll (hopefully) be responding soon!

 

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.

Theming Support in RSyntaxTextArea

Monday, November 14th, 2011

One cool new feature in the upcoming release of RSyntaxTextArea is theming support.  Currently, if you want to customize the fonts and colors used in RSTA, you have to programmatically use the SyntaxScheme and Style classes to do so.  This is actually very straightforward, but it also means you have to design your own UI if you want your users to be able to customize the editor in your application.  Many folks (not me :)) would find such a task tedious.

In the next release (and available for a preview in SVN), you’ll be able to completely customize RSTA via an XML file.  This allows you to externalize your customization logic from your application, and even deliver various “themes” if you so desire!

Theme XML is validated against the new theme.dtd.  You’ll notice that it allows you to set not only the fonts and colors used in the editor, but also those used by the gutter (assuming RSTA is wrapped in an RTextScrollPane).  There are a few sample themes already in the RSyntaxTextAreaDemo project.  These will probably get added to the main RSyntaxTextArea project, but won’t be a part of the actual library jar to avoid any more bloat.  Applications can feel free to ship these themes as-is, or modified, with themselves.

Using a theme couldn’t be simpler using the new Theme class:

   InputStream in = getClass().getResourceAsStream("/dark.xml");
   try {
      Theme theme = Theme.load(in);
      theme.apply(textArea);
   } catch (IOException ioe) {
      ioe.printStackTrace();
   }

Saving a Theme will be added once I have everything configurable via the XML.

Here’s an example of the “dark” theme currently checked in:

Dark Theme

Dark Theme

Code Folding Progress

Saturday, October 29th, 2011

I’m still making progress with code folding support in RSyntaxTextArea.  Several visual bugs were squashed (current line highlight, matched bracket painting when toggling folds), as well as a couple of “real” issues with the functionality.  The coolest thing that’s been added is folding support for XML:

XML Code Folding

XML Code Folding

Again, the actual rendering of the folded lines (color, the annotation at the end, etc.) is subject to change.  There are now also ways to do various folding stuff in the editor’s popup menu:

New Context Menu Items

New Context Menu Items

I’ll give these actions keyboard shortcuts moving forward, like those for Cut, Copy, etc.

Finally, note that, for any folded region, hovering the mouse over the “+” icon gives you a preview of the folded section, over-top where it would be in the editor:

Folded Content in Tool Tip

Folded Content in Tool Tip

Unfortunately, Ctrl+Print Screen in Windows doesn’t capture the mouse pointer, but you get the point!

Again, please try all this out by grabbing the latest from SVN!  Just call “textArea.setCodeFoldingEnabled(true)” and start tinkering with it.  Let me know any and all bugs you find!

Code Folding alpha added to SVN

Saturday, October 8th, 2011

Check out the lastest from Subversion to try out the WIP code folding in RSyntaxTextArea.  Simply call:

textArea.setCodeFoldingEnabled(true);

The fold indicator will be added to the gutter, and fold markers will appear where appropriate.  Currently supported languages include:

  • C, C++, C#
  • Java
  • Groovy
  • Perl

For other languages, there is no fold parser, so the editor won’t behave any differently than it used to (or shouldn’t!).  For the languages above, code blocks and multi-line comments are fold-able.  For Java, all import statements are also grouped together into a fold-able region.  Folding only currently works when line wrap is disabled – you won’t get any fold indicators if you enable word wrap.

Check it out and give it a go, but please keep in mind that this is an alpha feature!  There are likely lots of bugs.  Please report ‘em either by replying to this post or, even better, by posting them in the forums.

Also, I’m still playing around with the appearance of folded lines.  The little icon-ish thing at the end of folded lines (a la NetBeans) is temporary and probably won’t exist in the final version.  I’m trying to decide whether coloring the background of folded lines looks better than simply drawing a line across the editor.

Enjoy!

First baby step towards Code Folding

Wednesday, September 7th, 2011

I told myself I’d never do it, and it’s a feature I personally never use.  Some people agree with me, as evidenced by the second hit on Google for “code folding.”  Still, lots of people like it, and so in an effort to make RSyntaxTextArea as robust as possible, I’ve begun exploring code folding:

Code Folding

Code Folding

Nothing is checked into Subversion yet, but I’ve taken the first baby step.  Folding is done by a FoldParser interface implementation, so languages with differing ideas of what a “foldable region” is can be accommodated.  A “CurlyFoldParser” implementation will be available by default, that simply identifies foldable regions by curly braces (seen above).  This should be sufficient for the many languages out there with C-like syntax.  I already have several ideas to allow for easy extensibility as well, as far as fold parsing is concerned.

The FoldParser for a text area is called after a short time of no edits, similar to other RSTA Parser implementations, such as the built-in TaskTagParser and the SpellChecker add-on.  Folds are re-evaluated, and the fold indicator in the gutter is updated if necessary.

Of course, there are all kinds of crazy edge cases you never think about until you start implementing something – two or more folds starting on the same line, one fold starting on a line in which another ends,  etc.  I’m looking into how other editors handle such cases, and you’d be surprised how sometimes they aren’t as well-behaved as you’d expect (which is good for me, as I can copy their behavior and say things like “Well, Eclipse behaves like that!”).

In any case, this means that I’ll need folks willing to beta-test this feature before it’s included in an “official” RSTA release.  If you’re a user of RSyntaxTextArea and are ga-ga about code folding, please let me know and we’ll work together to make sure this feature is as bullet-proof as possible!

RSyntaxTextArea 1.5.2 Released

Saturday, August 27th, 2011

A minor update of RSyntaxTextArea and AutoComplete are now available on SourceForge and the Subversion repository.  Here’s what’s new:

  • Simplified the anti-aliasing API.
  • Java syntax highlighting updates to support Java 7 (binary literals, underscores in int literals).
  • Added an API to render tab lines (aka indent guides).
  • Fixed single-quoted strings in MXML.
  • Added miscellaneous keywords to Unix shell and Windows batch scanners.
  • Minor bug fixes.

Nothing earth-shattering.  The most noticeable update (and it’s not that noticeable, to me at least) is the anti-aliasing updates.  Not only is the API simplified (don’t know what I was thinking when I originally created it), but RSTA will now automatically pick the “best” anti-aliasing method to match the AA done by your OS, according to Java2D.  Font rendering has always been a sore spot for Swing applications, but with the later Java 6 updates, it’s actually gotten really, really good (at least on Windows).  Text rendering now (practically) matches that seen in native apps.  RSTA now handles specifying the AA hints the “right” way to look at nice as possible.

The next release will likely see more drastic changes, and will come along-side updates to the RSTALanguageSupport library as well.

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

Groovy: Variables in GStrings

Wednesday, June 29th, 2011

Another small update:  The screenshot below shows two updates to Groovy syntax highlighting in the next RSTA release:

  1. Variables and expressions in GStrings will be highlighted.
  2. (Some) regular expressions will be highlighted (hard to see, but the “/\d+/” is in brown).

Recent use at work had made my love for Groovy grow, so I decided to give back in the only way I know how.  :)

Highlighted expressions in GStrings

Highlighted expressions in GStrings

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!