|
Post by George on Jan 22, 2021 12:37:17 GMT -5
Robert:
Using a temp version of the line (with possible padding added) sounds good, but the main output from Search is 3 items. A line number, a column number and a length for the found string.
Change (and all other routines which use the common search routine) are totally driven by these three values. And all the modification routines expect there will be data present where Search says there is. I really don't relish going through all the routines that might be impacted by such a change to ensure they will still function with 'phantom' data.
You have to trust me, there's nobody else who understands this jungle of code. I've been struggling to get around this problem with a 'fix' (not that one has appeared). Significant re-writes of the logic are not going to happen. Killing Null string changes when MINLEN>0 is the way to go.
Stefan is probably correct in that there are inconsistencies in the logic. They've been there for years. Correcting them is also probably a significant re-write. And again, not gonna happen.
The source code is all out there, get a copy of PB and have a go. Any takers?
|
|
|
Post by George on Jan 22, 2021 15:57:51 GMT -5
Robert: I appreciate all this, and I'll have a serious look at it. Adding yet another FIND/CHANGE operand is a bit tedious, but ....
And then it means users would have to think about whether they need to add PAD to their FIND/CHANGE commands. This is definitely a non-ISPF compatible solution.
Other than trying to head off a Loop/Cancel, this is all becoming a bit much. We've "suffered' with this ever since MINLEN was added, and I don't recall being swamped in complaints from users. I'm not saying to ignore it, but it is becoming a 99% code to fix a 1% problem.
And it's just not interesting. Sorry, but that's my feelings.
George
|
|