|
Post by MUEH on Apr 25, 2018 6:41:55 GMT -5
EXCLUDE string NEXT doesn't exclude last line when repeated by RFIND PFK5 Test file //1 //2 //3 cmd X // 1 NEXT gives msg Excluded 1 line and line 1 is excluded RFIND gives msg CHARS // found and X'd and line 2 is excluded RFIND gives msg Bottom of data reached and Line 3 is not excluded fails for matching string in last line of file or line range . After RESET and repeated RFIND all matching lines are excluded . (no line range) if PREV is used last line is not excluded when starting with RFIND at Bottom NEXCLUDE has same problem (FIND or CHANGE are okay) When you change line 2 to A/ and repeat them 100 times it stops at line 227 when RFIND key is held down . if you start x f.e. at line 200 or 280 then it stops with bottom of data much earlier but always before last line . When PREV is used problem doesn't occure and we X all matches of the 303 lines up to the top . Is this a bug or is it working as it should ?
|
|
|
Post by MUEH on Apr 25, 2018 9:06:35 GMT -5
X // PREV has also the problem . when starting from line 200 the exclude it reaches the top and then excludes the next lines at line 237 instead starting at bottom .
|
|
|
Post by George on Apr 25, 2018 9:46:58 GMT -5
Thanks, I guess ;-))
These boundary issues are always tough to resolve without messing other stuff up. I'll have a look.
George
[UPDATE] This is becoming really convoluted. Going to take a while.
George
|
|
|
Post by George on Apr 26, 2018 10:21:44 GMT -5
OK, this certainly was a convoluted one. Here's what was going on, for those who like to understand better: - All commands that support search arguments (FIND, CHANGE, EX, SHOW, etc.) as part of their parsing logic, set up the search criteria in a separate saved data area for use of the RFIND command. This includes the default line range specification (which is defaulted to .ZF to .ZL)
- The line range is saved in internal specific line numbers at the time the initial command is executed.
- EXCLUDE, when it collapses a series of lines, inserts the ------ marker line, possibly adjusting the internal .ZL line number.
- RFIND uses the saved line number range which does not now encompass the adjusted .ZL location. Hence the error we're seeing.
So, I've corrected things so that if .ZL has moved, the saved RFIND criteria line range will be adjusted if it's end range was .ZL, to match the newly moved .ZL value.
Proves we're never done finding obscure bugs.
George
|
|
|
Post by George on Apr 27, 2018 13:38:24 GMT -5
Robert: Hmmm, the old visible line number vs internal line pointer problem.
I'm afraid that nearly all internal functions will be remaining as Line Pointers rather than Line Numbers. This is a pure performance issue.
Converting external line numbers into line pointers consists of a serial search of all text lines looking for a match, it is not some simple algorithm transformation. So my philosophy has always been to do conversion of line numbers to line pointers ASAP, and since line numbers can only come from user keyed inputs, the serial search overhead is not an issue as its only done once per user command.
And internal functions absolutely NEED to be in Line Pointer terms anyway, I can't even conceive of doing them using line numbers. Think of a MM/MM range moving to a BB3 destination. Tracking what line(s) go where in the midst of assigning new line numbers for the moved lines would be impossible.
Line numbers are for humans, it's simpler by far to handle conversion to/from pointers at the screen interface level.
George
|
|