George,
I think I haven't articulated this particularly well. Hope my replies to your points shed some light...
1) Assuming the Bnds table is built at file open time.
Sound sensible.
The only other time the Bnds table needs to be re-built is if the user modifies the TABS line in the profile during the edit session.
Note that the Right_Bnd() table needs an entry before the first tab stop and two entries after the last tab stop.
Entry 1 would be zero, (an unreachable column number)
Entry n+1 is either 'huge-number' or 'LRECL+1' for files with LRECL>0. If so, Entry n+2 is 'huge-number' (an unreachable column number)
2) The common routine CsrMode will constantly adjust CurBndIdx as the cursor moves.
I assume that's the most convenient place for such code.
BUT crucially, the value of curBndIdx does NOT "constantly adjust as the cursor moves".
curBndIdx needs 'adjusting' only when the cursor crosses a tab boundary, or when curBndIdx has become 'stale' (see reply to (4) below).
3) I assume (TabRelease) sets CurBndIdx to the huge-number index. The /n version similarly.
(TabRelease/n) is no more. Users can achieve same effect by placing a TAB in the appropriate column in the first place.
As for (TabRelease), it depends on the effect we choose to implement.
(a) If (TabRelease) should 'suspend/ignore' all subsequent (ie. right of cursor) tabs on the current line, then...
if LRECL = 0: Set curBndIdx = UBOUND(Right_Bnd(curBndIdx)), i.e. = huge-number
if LRECL > 0: Set curBndIdx = UBOUND(Right_Bnd(curBndIdx)) - 1, i.e. = LRECL+1
(b) If (TabRelease) should 'suspend/ignore' only the tab we crashed into and leave subsequent tabs intact.
INCR curBndIdx
4) The next character typed, or other action that moves the cursor will invoke 2) losing the (TabRelease) effect.
Let's look at these two scenarios separately:
(a) The next typed character loses the effect.
It won't lose the (TabRelease) effect, because typing (or deleting) a character does NOT change curBndIdx.
Right_Bnd(curBndIdx) marks the end-boundary of the current field; it 'identifies' the current field, i.e the field where the cursor is.
So curBndIdx only increases or decreases when the cursor crosses a tab boundary (moves from one tab field to another)
Once the value of Right_Bnd(curBndIdx) is 'hugenumber' (or LRECL+1 for fixed length), the current 'field' length is effectively endless (or up to max LRECL and endless beyond that).
The cursor will not reach column 'huge-number' let alone cross that boundary.
Hence the CsrMode routine would no longer INCREASE curBndIdx. It remains at the 'huge-number' (endless) entry.
For LRECL>0 files, the user can enter data up to column LRECL and then hit a keyboard lock.
If they force the issue and press (TabRelease) at this point, the next & last last entry in Right_Bnd() is huge-number, effectively endless line length.
(b) Other action that moves the cursor loses the effect
Any and every action that moves the cursor away from the current line invalidates the value of curBndIdx.
A mouse click to reposition the cursor, an RFIND command locating the next occurence, any of the many other (primitives) line command, primary command, cursor or mouse-wheel scroll... etc
Hence it is necessary to compare the new cursor position with the previous cursor position.
If the difference is one byte horizontally either way, curBndIdx is still valid.
Anything else, and curBndIdx must be reevaluated to determine in which tab field (if any) the cursor is now.
e.g. IF cursor-is-in-data-area THEN FOR curBndIdx = 1 TO n WHILE Right_Bnd(curBndIdx) < cursor-column : NEXT
Note that this also reset (TabRelease) automatically at the same time.
I guess the code to compare previous and current cursor position and reevaluate curBndIdx would also need to be in the CsrMode routine.
Also, I do not think adding Tab boundaries to CHANGE is something I would even tackle.
I see the confusion. I couldn't have put this more incorrectly if I tried! Sorry.
There's no suggestion that CHANGE (or any other primary or line command) should be influenced or affected by TAB boundaries.
When I mentioned 'commands' in my previous post, it was to cover the fact that Primary and Line commands often change the location of the cursor, both vertically and horizontally.
The explanation in (4b Other action...) above hopefully clarifies my intent.
