| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Bump the POM xml to the next snapshot version we'll be using
|
|
Renamed the test files so that their name gives a hint as to what it is
that they are testing, without having to open the file
|
|
Added a new test file, which tests how the body-inline multi-flags work
|
|
Messed around with the site configuration a bit, got the coverage to
start showing up in the side bar, along with the generated reports/other
information
|
|
Fix an outstanding issue w/ tests. why line-ending, why?
|
|
|
|
|
|
Cleanup some latent bugs
|
|
Pass to do some cleanup
|
|
Add some javadoc comments
|
|
Cleanup some warnings
|
|
Cleanup up some warnings that appeared
|
|
Fixed an issue, after a while away
Get to a known state
|
|
|
|
Pattern guards allow you to say that a particular pair should only be
replaced when the input matches a particular regular expression.
It is tied to the 'G' or 'Guard' control on the pair header, and is one
of the 3 or so major features I want to implement before a 1.0 release
As an aside, the other two features I want to add are:
Multibody Support
=================
This will allow a pair to replace to a few different things, based on
various conditions (the two main ones I want are some sort of cyclic
behavior, and some sort of guards for these)
Sub-application
================
Allow the application of a stage to the result of applying a pair/parts
of applying a pair. This will likely entail several sub-features such
as:
Named Stages
------------
A named stage is a collection of pairs that isn't applied by default,
but is instead used for convenient grouping of related pages together.
Custom Replacement
------------------
Instead of using replaceAll, I'll probably go for something using
appendReplacement etc. on Matcher and roll some sort of custom thing, so
as to provide for a convenient syntax for anything special I want to do
while running the replacement.
I'll also want to add some documentation, in addition to maybe doing
some restructuring to make how things are laid out more obvious.
|
|
|
|
Perform some maintenance/cleanup with StringUtils. Mostly just doing
some abstracting of stuff properly.
|
|
|
|
All of the places that parse controls now use ControlledString instead
of doing their own stuff. -\(o-o)/-
|
|
|
|
escapeSplit will now properly handle arbitrary length escape sequences
and do the right thing.
|
|
ControlledString now has support for parsing out control strings. Need
to come up with something so that ReplPair can use it as is, instead
of having its own implementation; plus, there are a few other
interesting things I can think of that could be added to
ControlledString
* named arguments to controls is one
* multiple named arguments
* store controls in controlled string by name instead of as ordinals
|
|
This is part one of factoring out controls and control parsing so that
we aren't doing it in three different places.
Two main things before this is done:
1. Finish up the parsing in ControlledString
2. Actually replace the old implementations in ReplPair
|
|
At the moment, all ReplSet is is a convenient way to wrap around the
interface of ReplPair in a convenient way.
It will probably have some extra functionality in the future, though I
am not sure of the details as of yet.
|
|
|
|
The main bug was that if you started the string with a delimiter, you
would only get an empty string as a result. Turns out endsWith("") is
usually true :-|
Also, added some more tests, and some more early outs to escapeSplit.
|
|
|
|
|
|
Things are now in package bjc.everge, not bjc.replpair
|
|
|
|
Added another test, this time for staging.
Also added some debugging capabilities.
|
|
|
|
The rest of the files, for initial upload to github
|
|
|
