1. Swing’s text package keeps a lot of handy implementation hooks private and package-private.
2. Swing’s text package’s idea of “selection” is pretty much hard-coded to mean “a contiguous range of text.”

In Java 6, #1 above has been (mostly) remedied, making it a good deal easier to implement this feature completely if your text component only supports Java 6+.  Unfortunately for us, RSyntaxTextArea supports from 1.4 up!

Because of this, adding block selection to RSTA will be tricky.  Fortunately, I’ve been motivated to finally put forth some effort to make this a reality.  I’ve added a branch in SVN specifically for exploring block selection, and already, a little progress has been made:

Block Selection

Obvious issues include:

• Cut doesn’t work properly (though Copy does)
• Drag-and-drop of a block selection doesn’t work (not sure this is possible, at least with pre-1.6)
• Typing over a block selection doesn’t have the “expected” behavior of typing on all block-selected lines

Hopefully more progress will be made soon!

• Groovy syntax highlighting updates (GDK Object methods, Java 5/6 java.lang classes, URL’s in comments)
• A fix to prevent security exception when setting AA hint in an applet (thanks to Frederic in the forums)
• Fixing positioning of FocusableTips and code completion windows on multi-monitor setups (thanks to grzlbrmft in the forums for the bug report and testing).  I’m personally jealous of everybody out there with a dual monitor setup, who got to experience this bug. 
  

  AutoComplete Windows

• AutoComplete’s description window now updates itself in response to a selection change after a small delay (120ms) instead of immediately, to help performance for language supports with slower descriptions (e.g. file IO).  This mimics Eclipse’s behavior.
• Added ActionScript syntax highlighting.  Perhaps now I have no excuse to play with this language.
  

  ActionScript

• Improved performance of auto-completion list cell renderer for huge completion lists.  Helps with languages with huge amounts of functions, such as PHP.
• When using SearchEngine, if the next match isn’t currently visible, center the found/replaced text after the search operation.  This is a seemingly small change but is a nice usability improvement, and is seen in better editors like Eclipse.  For example, if your cursor is here:
  

  Starting to Search

  And you used SearchEngine#find() in RSTA 1.4.1 to find the next instance of “clip”, the next instance would be selected and brought into the visible area like so:

  

  SearchEngine#find() result before 1.4.2

  Note that the next instance is selected, but is barely scrolled into the view.  Starting with 1.4.2, the next match is scrolled to the center of the text area, vertically:

  

  SearchEngine#find(), after 1.4.2

  If the next instance of the text you’re searching for is already visible, the editor is not scrolled, the text is merely selected.  If the next match is not currently visible, however, that’s when it will be scrolled to the center of the view.

• Fix for SourceForge bug 2998448: regex “replace all” is always case-sensitive.
• SearchEngine’s concept of “whole word” is more accurate now (allows for punctuation, such as ‘,’, at the end of words, for example).  Previously, a “whole word” had to be completely surrounded by whitespace.
• Added start of JUnit tests for SearchEngine.java.
• SearchEngine bug fixes for replaceAll() with regex and match case/whole word enabled.
• Fixed auto-complete bug with overloaded functions.
• Fixed auto-complete bug – capitalization should be corrected when completing a parameterized completion.
• Improved properties file syntax highlighting: ‘:’ can divide name/value pairs.
• Added “our” keyword to Perl syntax highlighting.

Grab it on the SourceForge page today!

There will be 3 main areas focused on in the 1.2 RText release:

1. Integrating the language support I’ve been blogging about (Java, HTML, Perl, etc.)
2. Usability improvements
3. Bug fixes

The first item is already practically done.  I’ve integrated RSTALanguageSupport via a plugin.  I’ve still got a couple more ideas for the latter two items before 1.2 is good to go.

Anyway, after a few requests, I’m adding what Eclipse refers to as Auto-Activation.  This means that you can have the completion popup appear automatically after certain characters are typed.  For example, typing a ‘.’ character in Java could cause the completion popup to appear after a small delay, removing the need to keep pressing Ctrl+Space.

The new methods are added to the AutoCompletion class, and look like this:

public void setAutoActivationEnabled(boolean enabled)
public boolean isAutoActivationEnabled()
public void setAutoActivationDelay(int millis)
public int getAutoActivationDelay()

These methods allow you to toggle not only whether auto-activation is enabled, but also how long the delay should be between when they stop typing and when the popup appears.  It can be set to 0, meaning to always appear when possible, but often users want a small delay (maybe 200 milliseconds), so that it only shows up if they genuinely need it and stop typing.

Note that auto-activation depends on auto-completion itself being enabled.  If you’ve called setAutoCompleteEnabled(false) on an AutoCompletion, it will not honor the auto-activation property.

As to what characters trigger auto-activation, that is done on a per-CompletionProvider basis, since this can (and should) vary depending on what programming language is being edited.  The CompletionProvider interface now has a method:

public boolean isAutoActivateOkay(JTextComponent)

that should return true or false, depending on whether the text at the current caret position is something that auto-activation should occur at.  The concrete base class, CompletionProviderBase (what all CompletionProviders actually extend from, allow you to set exactly what characters this method checks for:

public void setAutoActivationRules(boolean letters, String others)


The first parameter allows you to have auto-activation occur after any standard letter (e.g. Ascii).  I personally think this is annoying, but I have seen editors do it in the past (Visual Studio?).  The second parameter is a string, each char of which is treated as a char to auto-activate after.  So for example, with Java you could call “setAutoActivationRules(false, “.”)” to auto-activate after the user types a period.  For markup languages you could pass “<” as the “others” String to auto-activate for tag names after ‘<” is typed.

The RSTALanguageSupport library is already taking advantage of this new feature.  The Java, HTML, and PHP supports all now auto-activate after appropriate characters by default.  They’re extra smart, and won’t auto-activate when not appropriate (e.g. typing “foo.” while in Javadoc won’t start auto-completion in Java, or typing ‘<’ while in a comment or attribute in HTML – while invalid in and of itself – will not cause code completion either).  If you’re an early adopter, be sure to check out out!  It was first added in revision 209.

Perl options in RText

Here’s RText’s Options dialog, showing all the features related to Perl support that you can currently toggle.  As you can see, you can currently fiddle with both the code completion as well as the on-the-fly syntax checking I recently blogged about.  For the latter, you have to have a Perl install somewhere on your machine.  RText will scan your PATH for a Perl install, and default to using that, but you can change it to another installation if you want.  Still pending is the ability to add modules to the @INC path.

Language support will be fully integrated into all aspects of RText.  For example, compile errors and warnings will show up in the Error Strip component:

Compiler errors in Error Strip

Also, function descriptions are displayed simply by hovering the mouse over them.  For example, below, my mouse is over the “print” function (sorry screen captures in Windows don’t capture the mouse pointer):

Function descriptions on mouse hover

Perl is one of the harder languages to integrate, simply because its language support has so many features (runtime compilation, etc.) that others don’t have.  Hopefully other language supports will be integrated into RText shortly.  Stay tuned!

Perl Syntax Checking

Next will be the ability to muck with the @INC path to add other libraries.  Currently it only uses the default @INC of your Perl install.

If you check out the project, please read the readme file first.  It’s fairly up to date and explains how to compile and use the library.

The library currently includes code completion for the standard C library, and despite a couple of rough edges, should be mostly complete:

C code completion

C support takes advantage of the parameter assistance feature of the AutoComplete library as well:

Parameter assistance for C functions

There’s also the start of decent support for Java, which is much more robust and dynamic than the support for other languages such as C.  It actually evaluates your code when you hit ctrl+space, and gives you accurate completion choices based on your current location in the code, based on classes you’ve imported (referencing jars on your “classpath”), local variables if you’re in a method, etc.  This has been discussed in several previous blog posts.

Java code completion

Yes, that tree widget on the left is actually included in RSTALanguageSupport as well!  However, it is currently Java-specific, and will not display an outline of source code in any other language.  It’s not high priority at the moment to generalize it, but it should probably happen sooner or later.  Java also supports parameter assistance when completing methods, like C does with its standard library.

There’s also code completion for Perl, supporting all built-in functions in Perl 5.10.x.  Rudimentary support for completions of variable names will appear for Perl in the next couple of days.

Perl code completion

There’s also excellent support for HTML 5 – completion for all valid tag names, and attributes are suggested as well (only those attributes valid for the tag they are describing).  The description information displayed in the tool tip-style side window is rather lacking, however (as you can tell from the screenshot), so help improving this documentation is more than welcome!

HTML Completion

PHP code completion is also included.  It uses the built-in HTML support when editing HTML, but when the caret is within PHP tags, PHP functions are suggested instead.  There is no documentation for PHP functions in the description window like there is for other languages just yet.

PHP code completion

Similar to the C and Java support, parameter assistance is included for PHP functions:

Parameter assistance for PHP

Hopefully that is enough to whet some appetites!  Please discuss and ask questions over in the forums.

http://svn.fifesoft.com/svn/RSyntaxTextArea/TokenMakerMaker/trunk

The usual caveats:

1. I haven’t really worked on it since I last blogged about it, so it may have bugs.  It definitely has bugs dealing with the “multiline” string option.
2. The code isn’t pretty.
3. There will be no “official” releases for awhile, unlike RSyntaxTextArea, AutoComplete and SpellChecker.  If you want it, you’ll have to grab it from SVN.
4. Unlike all other RSyntaxTextArea-based projects, TokenMakerMaker requires Java 6 to run.  Since TMM is a developer tool and not a library, I don’t really see this as an issue, especially since even Java 5 has reached EOL.

While the project itself is open-source (probably LGPL, but I haven’t decided on a license just yet), any TokenMakers you generate from it are yours to keep – you can license them however you wish.  Do keep in mind however, that TokenMakers are only usable via RSyntaxTextArea, which is LGPL.

The TokenMakerMaker repository contains an Eclipse project.  To get it building error-free, you’ll also need to check out the RSyntaxTextArea project, and add it as a build dependency to your TMM project.  This is because TMM always uses the very latest bits of RSyntaxTextArea to keep them in-sync.

With both of the projects checked out, you can run TokenMakerMaker directly from Eclipse by launching org.fife.tmm.Main as a standard Java application.

Alternatively, you can build TokenMakerMaker, and launch it from the resulting executable jar.  To do so, you’ll need to first run the main target in the RSTA build.xml Ant script (“make-jar”).  This creates dist/rsyntaxtextarea.jar in the RSyntaxTextArea project, which is used by TokenMakerMaker.  Then you need to run the main target in the TMM build.xml script, which builds TokenMakerMaker.  The result is a stand-alone TokenMakerMaker application in TokenMakerMaker/dist.  You can run this application as follows:

cd rsta-projects-root/TokenMakerMaker/dist
java -jar tmm.jar

Here are some basic notes about using the UI:

• You can save and load your progress via Ctrl+O/Ctrl+S.  Your TokenMaker spec. is saved in an XML file.  This way you can come back and work on it later if you want, without having to dig into the generated flex.
• Once the app starts, the first thing you’ll want to do is go to File -> Options.  In the “General” panel you can specify a “working directory.”  This is the location that generated *.flex, and their corresponding *.java files, will be placed.  Change this to wherever you want.  I believe old files with the same name will be overwritten without prompting you if it’s okay, so be warned!  =)
• On the “General” tab, the difference between “AbstractJFlexTokenMaker” and “AbstractJFlexCTokenMaker” is that the latter will cause your TokenMaker to auto-indent after lines ending in ‘{‘, as well as auto-align closing ‘}’ chars when they are typed (assuming auto-indent is enabled in the RSyntaxTextArea it’s running in).  It’s supposed to be the option you want to pick if the language you are creating derives syntax from C, and uses curly braces to denote code blocks.
• The app is supposed to be smart, and if you don’t enter a value for a field that is required, you shouldn’t be able to generate anything without an error prompt.  But there may be issues I haven’t discovered yet.
• TMM assumes that the Java install running it is a JDK.  If it isn’t, TMM will still generate the .flex and .java source files for you, but it will not be able to compile the resulting .java file and allow you to test it in-proecess, which is one of its really cool features.  For this reason, I’d suggest running it with a JDK as opposed to a JRE.

Hopefully this is enough to get people started.  If you have any questions or issues, feel free to add a comment to this blog entry, or better yet, use the forums.

Source Attachments working

Beyond that, I’ve been working on the API, using RText as the test application.

Also, not the source outline tree on the left.  I’m working on getting this component simple and usable as well.  I’m tempted to shove it into the RSTALanguageSupport library, since it would only be used with RSTA instances using the library, but since it isn’t specifically related to the editor, it may just end up in RText itself.  It’s really nice – it displays the outline of the source as parsed by the code completion parser, and clicking on an item in the tree jumps to that item in the source code.  However, it is Java-specific and is not currently meant to be used for outlining just any language.

In getting this library tidied up, I’ve picked up the Java code completion yet again, since it’s by far the most complex.  I thought I’d give a status update now so people don’t have unrealistic expectations about the library when it’s first released.

Assuming you’ve added any jars you want on your “build path” (to use Eclipse terminology), the Java code completion support can handle:

1. Class fields and methods:
   

   Completion of fields and methods

2. Local variables in scope in the current method:
   

   Completion for local variables

3. Methods and static fields of non-primitive fields and local variables:
   

   More local variable completion

4. Common Javadoc completions that I personally find extremely useful in Eclipse:
   

   Javadoc completions

It does not currently handle completions for return types of methods:

Can't do this just yet

This is the single issue that will take the longest to resolve, as it’ll take a re-hashing of how the code completion is parsing the code.  Other features and bug fixes will appear before this one is fixed.

Also, please note that the Java code completion should not be considered “good design.”  I am (poorly) self-taught in lexing/parsing, and so what I have now is certainly not optimized, easy to read, or using the latest design techniques.  It is what it is.    I consider this to be a learning experience, and that the library will improve over time.

That said, it seems reasonably performant (only a pause when it has to initially load completions for many new classes, such as multiple imports of large packages, such as “javax.swing.*”), and is more than usable on the machines I’ve tested on.  Memory usage could certainly be improved (stuff isn’t shared between multiple editors implementing Java completion that should be) but I plan to fix that soon.

As a side note – as you can see from the first screenshot, I’m also working on tying Javadoc into the description window.  Notice that the Javadoc for the “str” field is nicely formatted in the tool tip-style side window?  That happens for all fields and methods in the current source file.  I’m also working on the ability to add “source attachments” for jars on the “classpath,” just like Eclipse, which will be used for assistance with libraries.  So for example, you can point to the src.zip included with your JDK, and get a nice description of each class, field and method in the JDK, just like in your favorite real IDE!

Integration of this library into RText as a plugin is already underway.  As always, RText will be a showcase of all the cool stuff you can do with RSyntaxTextArea.