It would be nice to be able to use regular expressions in the find-replace dialog.
Story: User realizes while searching that she doesn't remember the exact string she's looking for. She checks the "Use Regular Expressions" checkbox next to the "Find" field, enters an expression, hits Enter to begin the search, and then continues editing.
Implementation notes: We could use the jakarta RE package, which is also GPL code. The state of this checkbox should be maintained as an invisible config option, i.e. there's no need to edit it in Preferences, but its state should persist after closing DrJava.
Logged In: YES
user_id=343403
You could also use JDK1.4's regex stuff or actually abstract
above it and use whatever is available. I think there is a
bit inside apache ant that you could pull out which lets you
get a regex matcher from the set of ones it knows about
(jakarta, JDK1.4, etc) without depending on any at compile
time and with the ability to trivially degrade if no regexp
matcher is there. This would let you keep from adding to the
size of the download for everyone, yet still have RE support
if using JDK1.4 or is regexp.jar is on the classpath.
Logged In: YES
user_id=431096
The problem with Jakarta's regexp isn't size, but license. It is
only a 29k binary, but it's under a non-GPL license. (I was
wrong in that statement above.) Apache says that it is
compatible with the GPL, but the FSF disagrees. What a judge
would say is anybody's guess. There's a good chance that the
FSF would also consider the DynamicJava license incompatible,
since its terms are similar to those in the Apache license. We'll
have to discuss the implications and come to some kind of
consensus about whether we can use it.
Logged In: YES
user_id=431096
Okay, I finally did the smart thing and Google-searched for
libraries. Here are my best results:
<http://regex.info/java.html>
<http://tusker.org/regex/regex_benchmark.html>
There are several options in these lists that use the LGPL,
which works well with our existing license mix. One uses an
Artistic License, and one uses the full GPL.
None of them perform poorly enough or have huge enough of a
footprint for us to really worry about it. All of them support
slightly different features with a slightly different interface, so
it might be worthwhile to abstract over them. Then again, this
is a low-profile feature, so we may not care enough to bother.
I guess the XP way would be to implement it now and
abstract later if necessary.
Logged In: YES
user_id=343403
You could just use JDK 1.4 regex support if it is present or
have the feature disabled if not?