Fifesoft Blog

http://forum.fifesoft.com no longer exists.  I could simply not keep up with the amount of spam posted to it, and the GitHub site is a much better place for Q&A and bug reports anyway.

Just committed to Git is a new feature:  Clipboard History.  Pressing Ctrl+Shift+V (Cmd+Shift+V on OS X) will cause the “clipboard history” popup to appear below the current caret position:

Clipboard History

This popup displays the most recent snippets of text added to the clipboard.  This allows you to paste any text that was *recently* on the clipboard, not just what’s *currently* in the clipboard buffer.  This is pretty useful if you’re a frequent copy-paster.

The clipboard history is implemented as a singleton instance of the org.fife.ui.rtextarea.ClipboardHistory class.  You can access it, but currently the only interesting thing you can do is set its maximum size.  By default, it only remembers the 12 most recent entries on the clipboard that can be interpreted as plain text.

While I’ll certainly not put much time into learning JavaFX, I did poke around at it a little, and it is a nice API.  It’s better designed than Swing, and easier to write clean code in.  In any case, I decided to see how RSyntaxTextArea worked in a JavaFX app, now that JavaFX 8 “fully” supports embedding Swing components into JavaFX apps.

It was pretty easy to do, and at first glance, worked great:

RSTA in JavaFX

However, I hit a big snag:  When I resized the window, (what seemed like) every other repaint resulted in everything *but* the Swing content being unpainted!

RSTA in JavaFX – Flicker

I say every other repaint, because slowly resizing the window you would see constant flicker, between blackness instead of JavaFX rendering, and the JavaFX goodness you were supposed to see.

I took out the RSyntaxTextArea, this does not happen.  So this does not seem to occur in JavaFX apps with no Swing embedded in them.

I added in a JButton instead of the RSyntaxTextArea.  The flicker did not happen.  So it seems to not be all Swing content that does this.

I replaced the JButton with a JTextArea.  The flicker came back.  Okay, so it’s only *certain* Swing components.

Note that there is flicker with stand-alone JTextAreas/RSyntaxTextAreas; JScrollPanes don’t have to be in the equation to see this issue.

So what’s the deal?  Somehow certain Swing content causes the JavaFX rendering pipeline to bug out.

Just a belated note that RSyntaxTextArea 1.5.0 was released a little bit ago on SourceForge.  Updates to the AutoComplete library are included as well, not to mention a (still Subversion-access only) new, 0.7-release of RSTALanguageSupport.  Download ’em today!

Some highlights of the improvements include:

• Clojure syntax highlighting
• MXML syntax highlighting
• Java code completion improvements
• Perl code completion:  Editing the PERL5LIB environment variable is now possible for advanced users
• Lots of bug fixes contributed by users

There are a couple of very minor things that might spur a 1.5.1 release pretty quickly, but this is a worthy upgrade from 1.4.x in and of itself.

Expect a new RText release pretty soon to showcase all of these new features!

I’ve gotten several requests asking for the ability to add syntax highlighting for custom languages to RSyntaxTextArea.  Because of the way it is designed, RSTA doesn’t lend itself well to this type of thing.  Creating a highlighter that just read through a properties file (or XML) and highlighted stuff via regular expressions would probably not perform well enough for most people.  But the learning curve for how to hack at JFlex-generated output so that RSTA is happy with it is also rather high.

So I’m working on a new tool, called, for lack of a better name, “TokenMakerMaker” (name suggestions are welcome!).  RSTA has uses a TokenMaker class to know how to highlight for a given language, such as Perl or Java.  TokenMakerMaker is a GUI program that allows you to enter the specifications for your language – keywords, comment delimiters, data types, etc.  It can take that input and generate the JFlex input file for your TokenMaker, as well as the actual Java source for your TokenMaker (it’s hooked into JFlex).  Further, if you’re running TokenMakerMaker with a JDK, as opposed to a JRE, it can compile the Java source generated and allow you to test it out in an RSyntaxTextArea instance, at design time!

This tool is nice because the generated scanners will be extremely fast (optimized by JFlex).  In fact, they should be every bit as fast as the scanners that come built into RSTA.  The key will be making the UI give as many options as possible so that what a generated scanner can do isn’t too rigid.

To test it out, I’m using it to generate a (simplified) TokenMaker for Java.  How is it looking so far?  Well…

Here’s a screenshot of the panel allowing you to define the comment delimiters:

Defining the comment delimiters for Java in TMM

And the panel allowing you to define the data types:

Defining the data types for Java

And here’s the testing window you get after clicking “Generate”:

Testing our generated Java TokenMaker scanner

It’s still early on but I hope to have a few people test it out soon.  Here’s what’s left to be done:

1. Flesh out the UI
2. Add panel for defining standard library functions
3. Add more configurability for Strings (escapes allowed or not, etc.)
4. Allow saving TokenMaker definition to XML.  Create batch tool to generate .flex/.java directly from XML to facilitate automation of the process

If you’d like to try this tool out early and provide feedback, let me know!

Due to popular request, I’ve started working on a simple spell checker add-on for RSyntaxTextArea.  The work has been pretty straightforward so far, and there is already even a project in SVN for it.  The add-on will be a small jar you put on your classpath, and with a couple of calls you can hook it into any RSyntaxTextArea instance.

It’ll spell-check comments in source code, or the entire file if you are editing plain text.  Spelling errors are squiggle-underlined with the color of your choice, and tooltips are available offering any spelling suggestions.  Here’s a teaser screenshot:

The actual spell checking functionality is handled by Jazzy, an open-source spell checking engine for Java.  Luckily Jazzy is LGPL just like RSyntaxTextArea, and so that’s also the license this add-on will be released under.

If you download the preview from SVN, please keep in mind that it should be considered an alpha release.  I already have some more changes I’ve yet to push, and the API may change slightly before being officially released.  But feel free to play with it and offer suggestions!  It probably doesn’t work with the 1.3.4 release of RSTA, it probably requires the latest in the trunk for that project as well.

I’ve finally gotten around to adding regular expression content assist (aka AutoCompletion) to the RText search dialogs.  This of course takes advantage of the AutoComplete library I’ve blogged about previously. There was a sticky issue with window focus, but I’ve managed to fix that up.

The functionality is similar to that found in Eclipse. When the “Regular Expressions” checkbox is checked, a little light bulb icon is displayed beside the “Find” or “Replace” text fields whenever they are focused. This means you can hit Ctrl+Space and get a list of regex constructs available at the current caret position:

Regex Content Assist

In other news, AutoComplete has been improved to better support right-to-left languages, such as Arabic. It detects if the text component it’s installed on has an RTL ComponentOrientation; if it does, the completion popup and optional description window will also be RTL.

Commit 97 in SVN improved Mark Occurrences support behavior in RSyntaxTextArea. Previously, there were two issues with it that were kind of annoying:

1. The Mark Occurrences highlights were always painted “on top of” the selection. This was because of how Swing highlighting support is implemented – highlights are always painted from most-recently added to least-recently added. Since text selection is actually a highlight, if you selected text after say some occurrences of a variable were marked in the document, the variable occurrences’ highlights get painted on top of the selection’s highlight.
2. When typing characters at the end of a Mark Occurrences highlight, those chars got “absorbed” into the highlight. Again, this is because of Swing’s highlight implementation. All Highlights have this behavior in Swing.

These issues are fairly simple to work around, but require writing a little more code (much of which unfortunately has to be duplicated from Swing classes, since the Swing text package is keen on keeping useful things package private).

This change will be in 1.3.3, which will hopefully be released soon.