Archive for the ‘AutoComplete’ Category

RSyntaxTextArea 2.5.2 Released!

Sunday, March 9th, 2014

RSyntaxTexArea 2.5.2 was just released on GitHub!  Here’s what’s new:

RSyntaxTextArea:

  1. Whether or not curly braces denote code blocks is now handled on a language-index level, not per TokenMaker. This means TokenMakers such as HTML, JSP, and PHP can provide auto-indentation and curly brace closing for ‘sub-languages’ such as JSP and CSS.
  2. Java syntax highlighting updated for Java 8 classes, interfaces, and enums.
  3. Added “mark occurrences” support for HTML.
  4. Curly braces can now be automatically closed when editing CSS.
  5. The SearchEngine class now automatically selects the next match after a Replace operation.
  6. Fixed errors when loading/saving Theme XML.
  7. Fixed several bugs.

AutoComplete:

  • Only minor changes to support/stay in sync with RSyntaxTextArea 2.5.2.

RSTAUI:

  • After doing a “replace” operation with the Replace tool bar, the next valid replacement region is selected in the editor.

RSTALanguageSupport:

  1. The JavaScript language support can now use JSHint for its squiggle underlining of errors and warnings. A .jshintrc file can be specified to override the default JSHint behavior.
  2. CSS code completion.
  3. Fixing bug in XML outline tree for XML files with DTDs specified.

The SpellChecker library was not updated; the 2.5.1 release is still the most current, and is compatible with RSTA 2.5.2.  The idea is that the most recent 2.5.x versions of all of the sister libraries are all compatible with one another.

Enjoy!

RSyntaxTextArea 2.5.0 Released!

Monday, August 26th, 2013

RSyntaxTextArea 2.5.0 was just released on GitHub!  The sister libraries AutoComplete, SpellChecker, RSTAUI were updated as well.  Here’s what’s new:

  • The minimum required JRE for the libraries was bumped up to Java 5 from 1.4.  There was no hard requirement for this from a feature point of view, but it allows us to fix a few issues here and there, and modernize the code base, which is a boon for developers.
  • Improvements in both the painting code and syntax parsing code.
  • Added syntax highlighting and code folding for .htaccess files.
  • Bug fixes in JavaScript and Clojure syntax highlighting.
  • The source repositories were (obviously) moved from the old SVN repositories hosted here on fifesoft.com to GitHub.
  • A few other minor changes.

Check it out and let me know what you think!

RSyntaxTextArea repositories now on GitHub, require Java 5

Sunday, August 11th, 2013

Two big things going on with RSyntaxTextArea!

First, the source for RSTA ia being moved from our personal SVN server to GitHub.  Since GitHub is the place to host open source projects these days, hopefully this new home will provide RSTA with more exposure and accessibility.  AutoComplete, SpellChecker, and the other sister libraries are moving over as well.  I haven’t quite decided yet what will happen to the current SVN server; my current idea is to keep it up and available, but to edit the readme files and Ant scripts to talk about the new location (and not actually build anything in the case of the Ant scripts, to force people to notice!).  But I can’t decide whether it’s better to just remove the repository entirely – that will force users to see it’s no longer there, causing them to go to the site and realize the source is now on Github.  While it’s a little more harsh, it will keep the project from appearing “dead” to people who simply monitor the SVN and see no updates being made.

The second big change is that, starting with the next release, RSyntaxTextArea will require Java 5.  Yes, I’m finally retiring support for Java 1.4.  If you still need to run on such an ancient JVM, you can continue to use 2.0.7 (or even fork it on Github!).  If any huge issues are found I’ll be happy to create a maintenance branch based off 2.0.7 for you Java 1.4 folks, but I seriously doubt that’ll happen.

Migrating to Java 5 doesn’t do much for the library itself, but it does modernize the code base, and fixes a couple of odd issues here and there.  You’ll find “java5″ branches in each RSTA project now; that’s where all the action is.  I’m trying to embrace git’s painless branching and all.  :)  When the work is finally done (should be in a day or two) I’ll merge these branches back into master.

Finally, I’ll be adding all known issues into the GitHub issue tracker and any other bits and pieces left remaining.  As an aside, I’ve found GitHub’s interface to be painless, fast, and intuitive.  Much better than the clunky old SourceForge interface.

RSyntaxTextArea – Plans for Next Release

Sunday, June 9th, 2013

Because I haven’t had much time to work on RSTA lately, I’ve been thinking about making a list of work items in an attempt to get motivated.  So here’s what’s on the list so far for the next RSTA release:

  • Performance improvements, particularly for word wrap with very long lines.  This has been asked for a couple of times in the forums.  I’ve done some work, that will be available in the next SVN commit, that will improve performance to some degree.  One of RSTA’s primary issues here is that modelToView()/viewToModel() calculations are relatively expensive, and for very long word-wrapped lines, they are called literally dozens of times whenever text is inserted or the window is resized.  As a first pass, I’m refactoring things a bit so that the data used by these method calls is cached much more aggressively; this seems to improve things quite nicely.  Moving forward, I might also try to minimize the number of calls to these methods in general, though that will be a more difficult task.  There were also some performance improvements made to WrappedLineView.java in the JDK, around the Java 5 timeframe, that RSTA may be able to learn from/graciously borrow.
  • Syntax highlighting for R.
  • Syntax highlighting for .htaccess files.
  • API in AutoComplete libarary to specify the expected type of arguments in a parameterized completion.

Any other suggestions?

RSyntaxTextArea 2.0.7 Released

Sunday, April 28th, 2013

RSyntaxTextArea 2.0.7 was just released on SourceForge!  Here’s a list of the cool new stuff:

  • setBracketMatchingEnabled(boolean) now checks for brackets “to the right” of the caret if one is not found “to the left.”
  • Added API for applications to create custom hyperlinks in RSyntaxTextArea, though this API should not be considered stable.
  • Added “mark occurrences” support for XML. Currently just highlights the tag name at the current caret position and its match.
  • Fixed issue when auto-inserting spaces for tabs.
  • Major refactoring of rendering code.
  • “Traditional” selection rendering is now supported; that is, selected text can now be rendered as syntax highlighted tokens with a “selection” background (as it was previously), or as text as a single color with the “selection” background (as standard text components do). See RSyntaxTextArea.setUseSelectedTextColor(boolean).
  • Fixed performance issue in FoldingAwareIconRowHeader when it paints “active regions.”
  • Added some new token types to better differentiate markup tokens from “regular” language tokens. This allows for better syntax highlighting for stuff like HTML, JSP, and PHP.
  • JavaScript highlighting now highlights JSDoc.
  • Added Visual Basic syntax highlighting.
  • In RSTAUI, a new TextFilePropertiesDialog was added.  This dialog shows the currently edited text file’s path, size, word count, encoding, line terminator, and more.  Further, when using a TextEditorPane, you can modify the file’s encoding or line terminator directly from the dialog.
  • RSTALanguageSupport: Miscellaneous JavaScript code completion improvements (thanks Steve).
  • RSTALanguageSupport: JavaScript code now syntax highlights JSDoc.
  • RSTALanguageSupport: JavaScript code completion now offers suggestions for JSDoc when in documentation comments.
  • RSTALanguageSupport: HTML, PHP, JSP and XML now have an option to automatically add closing tags when opening tags are typed (e.g. add “</foo>” when “<foo>” is typed). By default this option is enabled. HTML, PHP and JSP only auto-close tags closeable in the HTML 5 spec; XML closes all tags. This option is separate from the XML “auto-complete closing tag name when ‘</’ is typed” option.

Below are a couple of screenshots showing off the new JSDoc syntax highlighting and code completion.  The first one shows auto-completion kicking in after typing “@” in a documentation comment.  The second screenshot shows the parameterized assistance you get for “@param”:

JSDoc Code Completion

JSDoc Code Completion

JSDoc Parameterized Completion in action

JSDoc Parameterized Completion in action

Go check it out!

RSyntaxTextArea 2.0.6 Released

Wednesday, January 23rd, 2013

RSyntaxTextArea 2.0.6 was just released on SourceForge!  Included are new versions of AutoComplete, RSTALanguageSupport, and SpellChecker.

RSTA now provides syntax highlighting and code folding for JSON:

JSON Support

JSON highlighting and code folding in RSTA

Further, the AutoComplete and RSTALanguageSupport libraries now look good in Substance (in particular, Insubstantial).  Previously, these libraries used DefaultListCellRenderer for their completion choices.  Substance, being the barrel of fun that it is, forces libraries to extend its own DefaultSubstanceListCellRenderer, otherwise they aren’t rendered with Substance’s striping, gradients and rollover effects.  Now, RSTA and its cousins detect when Substance is the current Look and Feel, and render with a DefaultSubstanceListCellRenderer when necessary.  Easy peasy!

 

Substance in AutoComplete Popups

Substance in AutoComplete Popups

(Pardon the fact that I didn’t update the editor color scheme to be dark as well!).  This is done via reflection, so there is still no build dependency on Substance.  This of course assumes that the DefaultSubstanceListCellRenderer class name and package don’t change in future releases of Insubstantial, but I highly doubt that’ll happen, considering it’s a maintenance fork of the original Substance.  And if something goes horribly wrong, the library should fall back into its default rendering path anyway.

The outline trees (JavaOutlineTree, XmlOutlineTree, etc.) still use DefaultTreeCellRenderer, but applications can use the same technique here – wrap the standard renderers for these components with SubstanceDefaultTreeCellRenderer, call delegate.getTreeCellRendererComponent(), then set the Substance renderer’s icon and text based on the delegate’s values.  Come to think of it, I’m not sure why I didn’t have the libraries automatically delegate like I did with the completion choices lists… maybe next release.  One thing you do lose from this delegation is the rollover effect – the render “looks” the same, but the animated rollover effect depends on the actual renderer being a DefaultSubstance*Renderer.  Since we’re only *delegating* to one, we’ll look like it, but won’t get the rollover effect.

RSyntaxTextArea 2.0.5.1 Released

Monday, December 17th, 2012

RSyntaxTextArea 2.0.5.1 was just released on SourceForge!  This release fixes the problem with typing the ‘/’ character on non-QWERTY keyboards, so is a must-upgrade if you’re using 2.0.5 (2.0.4 did not have this bug).  It also updates the Arabic translation (thanks Mawaheb!).

The AutoComplete, SpellChecker, and RSTAUI add-on libraries were also updated with Arabic translation updates.

RSyntaxTextArea 2.0.5 Released

Wednesday, November 21st, 2012

RSyntaxTextArea 2.0.5 was just released on SourceForge!  Here’s a recap of what’s new:

 

  1. Code folding added for HTML, JSP, and PHP.
  2. Added NSIS syntax highlighting and code folding.
  3. Added code folding and highlighting of multi-line strings for Scala.
  4. Added Java 7 features to Groovy highlighting (underscores in numeric literals, binary literals, and new core classes/interfaces/enums).
  5. Wildcards can be specified in Go to Member dialogs.
  6. Tool tips can now be specified for icons in IconRowHeader.
  7. Fixed an issue with CompleteMarkupTagAction and ToggleLineCommentAction conflicting with each other only on *nix (Windows and OS X didn’t have this issue).
  8. Allow for non-ConfigurableCarets to be set via setCaret(), to allow for Swing’s “composed text” changes (hidden in private API).
  9. Fixed possible NPE in XmlTreeCellUI for environments where desktop AA hints cannot be determined.
  10. Updated translations – Italian (Argaar), German (Domenic), Korean (Changkyoon), Japanese (Josh), and Hungarian (Zityi).

Enjoy!

RSyntaxTextArea 2.0.4 Released

Sunday, September 2nd, 2012

RSyntaxTextArea 2.0.4 was just released!  Grab it either from SourceForge or SVN (see also web viewer, javadoc).  This release updates RSTA as well as the sister projects AutoComplete, RSTALanguageSupport, and SpellChecker, and adds yet another sister project:  RSTAUI!  Here’s the complete list of what’s new:

All:

  • Updated translations:  Chinese (peter_barnes), Russian (Nadiya), Polish (Chris), Spanish (Leonardo), Brazilian Portuguese (Pat), and Korean (Changkyoon).
  • Removed superfluous build warnings from projects when building with Ant 1.8+ (includeantruntime).

RSyntaxTextArea:

  • HTML, JSP, and PHP syntax highlighting now also highlight embedded CSS.
  • Background color highlighting for “secondary” languages (such as CSS and JS in HTML, JSP, and PHP).
  • Added code folding for Lisp and Clojure.
  • Minor Clojure syntax highlighting updates.
  • Changed default font to Consolas on Windows Vista and 7.
  • Decreased memory usage required for regex find and replace operations.
  • Improved performance of Mark Occurrences, especially when there are lots and lots of marked occurrences.
  • Added E4X highlighting to JavaScriptTokenMaker (can toggle on and off via a static property).
  • Added a property so that, when bracket matching is enabled, you can choose to have both brackets highlighted instead of just the “opposite” one.
  • Fix to RTextScrollPane class to facilitate using it in the NetBeans GUI designer.
  • Fixed misaligned icons in row header when code folding is enabled.
  • Fixed bug: FoldManager incorrectly auto-expanded deeply-nested folds for some edits that did not affect those folds.
  • Fixed bug: wrong initial width of line number margin when calling Gutter#setLineNumberingStartIndex(int).
  • GoToMemberWindow: Fixed occasional NPE.
  • TextEditorPane: Fixed bug: clear undo stack and dirty state when “loading” a new file.
  • TextEditorPane: Now automatically scrolls to top of file on load().
  • Fixed bug: NPE in DumbCompleteWordAction in some circumstances (whitespace at beginning of file).
  • TokenMakerFactory now allows user-defined TokenMakers to be loaded via different ClassLoaders.

AutoComplete:

  • Added template completions.  You can now create completions for constructs that have arbitrary structure and take any number of parameters, such as for-loops and other common boilerplate code.
  • Fixed memory leak when uninstalling AutoCompletes from text areas.

RSTALanguageSupport:

  • Tremendous updates to JavaScript code completion and syntax checking, all done by steve.  We now use Rhino 1.7R4 for parsing.  JS is now by far the best-supported language in RSTALanguageSupport.
  • JavaLanguageSupport: Much better display of Javadoc links in Javadoc completion popup.

RSTAUI:

  • New (optional) library providing fully functional, localized dialogs for Find and Replace operations in RSyntaxTextArea.  Supports searching forward and backward, regex searching, match case, mark all, and replace all.  The actual search operations are delegated to the RSTA library’s built-in SearchEngine class.
  • More common dialogs will be added to this library in the next release.  More information about this in a future blog post!

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.