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.
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:
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:
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!
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:
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:
And the panel allowing you to define the data types:
And here’s the testing window you get after clicking “Generate”:
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:
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:
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:
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.
AutoCompletion has enough features now where I’d really like other people to start trying out. So I’ve added a little space for it on fifesoft.com describing what it is and (soon) how to use it. There’s a nice WebStart example there of an editor for C with code completion for the C standard library. The Javadoc is up as well. All that is needed now is a couple of examples to get people started.
I also can’t decide if AutoComplete warrants its own SourceForge project, or if it can just be a subproject of RSyntaxTextArea. While the library can be used on any JTextComponent, auto-completion is usually used in IDE’s and programmer’s editors, and AutoComplete does come with special hooks to work better with RSTA. On the other hand, being a separate project may allow it to be discovered and used by a larger audience. Decisions, decisions…
Newly added to the AutoComplete library is parameter assistance… I’m not sure what you should actually call this feature, but it’s the one where typing a ( character causes a little tooltip to pop up describing the parameters for the function you’re entering:
Parameters are entered with default values. You can use tab and shift+tab to navigate through the parameters (ala Eclipse or NetBeans). The parameter you’re entering (separated by commas, for example) is highlighted in bold in the tooltip, and (if available), a short description of the currently active parameter is displayed.
This feature is configurable, just like the other autocomplete options, and can be turned off if you don’t have time to enter descriptive information about everything available to auto-complete.
I plan on making a very early release available on SourceForge this week. I’m interested in getting as much feedback as possible! As far as I know, RSTA and the AutoComplete library is the simplest way to get easy and powerful IDE-style features into Swing applications.
A minor update to RSyntaxTextArea will also be released, fixing a couple of minor bugs that have been reported by users.