Is the code checked into a sourceforge repository?
The reason I ask is that I have a change I wanted to diff against the trunk and post for possible inclusion. So that begs the question how do you want changes?
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The code is not in any repository as I am the sole developer.
It is quite easy to create your own local repository to merge your changes in to a later version of the library, or just use a diff tool such as KDiff3 to highlight where your code differs from the trunk.
The first step however would be to post a description of your changes and make a case for their inclusion in the core library. Then you can just email me any source files.
Cheers
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is what I've changed. In the OutputDocument class I added a method called setIgnoreOverlap(). It does just what it says.
Without my changes the code works like this. Take the following document:
<tag1><tag2/></tag1>
If I first replace <tag2/> with "bob" and then I replace the entire tag1 element segment with "hi". When writing out the new document I would get "hibob". With my change - and after I called setIgnoreOverlap() - the output would be "hi". I have all kinds of reasons for wanting the output this way but I will not go into them here.
So the reasons for wanting this in the core library are:
1. I don't want to keep track of this change ;)
2. It is a nice feature to have.
3. It does not break existing code that uses the OutputDocument class.
4. As you can imagine the change is relatively simple.
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the suggestion. I can't see any reason why this behaviour shouldn't be automatic rather that requiring a call to a setIgnoreOverlap() method. Since overlapping output segments are currently documented as producing "unexpected results", it is probably safe to assume that there are no programs relying on the current behaviour.
I will make the change in the 2.6-dev package and let you know when it is publicly available (probably within the next few days).
Cheers
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is the code checked into a sourceforge repository?
The reason I ask is that I have a change I wanted to diff against the trunk and post for possible inclusion. So that begs the question how do you want changes?
Brian
Hi Brian,
The code is not in any repository as I am the sole developer.
It is quite easy to create your own local repository to merge your changes in to a later version of the library, or just use a diff tool such as KDiff3 to highlight where your code differs from the trunk.
The first step however would be to post a description of your changes and make a case for their inclusion in the core library. Then you can just email me any source files.
Cheers
Martin
This is what I've changed. In the OutputDocument class I added a method called setIgnoreOverlap(). It does just what it says.
Without my changes the code works like this. Take the following document:
<tag1><tag2/></tag1>
If I first replace <tag2/> with "bob" and then I replace the entire tag1 element segment with "hi". When writing out the new document I would get "hibob". With my change - and after I called setIgnoreOverlap() - the output would be "hi". I have all kinds of reasons for wanting the output this way but I will not go into them here.
So the reasons for wanting this in the core library are:
1. I don't want to keep track of this change ;)
2. It is a nice feature to have.
3. It does not break existing code that uses the OutputDocument class.
4. As you can imagine the change is relatively simple.
Brian
Hi Brian,
Thanks for the suggestion. I can't see any reason why this behaviour shouldn't be automatic rather that requiring a call to a setIgnoreOverlap() method. Since overlapping output segments are currently documented as producing "unexpected results", it is probably safe to assume that there are no programs relying on the current behaviour.
I will make the change in the 2.6-dev package and let you know when it is publicly available (probably within the next few days).
Cheers
Martin