v22106 Beta: TRACK/TRACKF

Stefan:

Does loading or RELOADing a file clear the TRACK history?
   Yes, I'll add it to the Doc.

(1) No messages

If you press the (TRACK) or (TRACKF) key when there are is no TRACK history yet, NO message occurs.

   I figured a programmatical 'shrug' was OK, but I've added a message.


(2) Cursor is left somewhere along the command line

Load a file

Issue FIND <something> (pick a <something> that occurs on multiple 'pages' of the file. Note that the cursor is on command line behind the <something>)

Press RFIND key a few times to step/page down the file

Press (TRACK) a few times until you're back at the start page or "No further TRACK entries" appears

All works great, with the cursor on the, now empty, command line, but still in the column after the <something>. Should probably be at colunm 1 of the command line.

   The creation of a 'Track Point' is simple minded, it has no idea where the cursor is, only that it must be saved. I'll look at some special code for the command line - yet another kludge.


(3) Gremlins with (TRACKF) - probably all related

a) Issue RESET TRACK

If you press the (TRACK) key, you see the message "No further TRACK entries"

But if you press the (TRACKF) key, it corrupts the display.

I run with COLS ON for convenience. So the top 4 lines on my display are usually





but after a (TRACKF) there's an extra line between the 'COLS' and 'Top of Page'. It shows a 'blank' in the screen shot, but appears as a repeat of whatever was the first line before.

In this example, I see two 'Top of Page' lines.



b) The same happens if you do as in (2) above, but instead of TRACKing all the way back to the start, you just TRACK back one step/page and the press (TRACKF).

Spot the extra line at the top of the screen.


I couldn't get the corruption you saw, but the RESET TRACK needed a tweak. Hoping its gone now.


c) Issue FIND <something>

Press RFIND key a few times to step/page down the file

Press (TRACKF)

I know this is daft, but it results in message "TRACK Top-of-Screen line no longer exists"

I think this is also corrected.


d) I have also experienced, but can't reliably reproduce, this.

Build a TRACK history (as in (2) above)

Issue RESET TRACK

Press (TRACKF)

(TRACKF) tries to jump forward anyway.

At one point, the 'data' portion only filled half my screen and (TRACKF) placed the cursor way below the 'Bottom of Screen' marker.

(This may have involved some 'excluded lines' on the display. I'm still trying to reproduce this.)





Hope this helps you to to track down the gremlin(s).



(This next bit is very tricky and should perhaps remain unchanged and merely acknowledged by you with a shrug of your shoulders)

I'm still teasing(!) the new logic with excluded lines.

You seem to 'track' the top line on the display by 'data line', and so far, it is correct for every case I've tried.

But the cursor seems to be positioned PHYSICALLY on the screen rather than tied to data line.

For example:

(My window sizes allows 60 'data' lines to be displayed per page.)

The display is showing Line NUMBER 3 as the top line on the page and line NUMBER 62 is the last visible line on that page.

I enter a FIND <something> command (which will jump to another page) but don't press <ENTER> yet.

I also enter a XX line command on lines 10 and 19 (ie. 10 lines will be excluded) block but still don't press <ENTER>

I change some data on line 44, (which is PHYSICALLY the 42nd line on the page), leaving the cursor on that line and now press <ENTER>



I assume that the execution sequence is: XX..XX block is done first, then TRACK capture, then the FIND command.

So at the time of the <ENTER> key...

- top of page is line number 3

- cursor is on data line 44 column <whatever>, which is PHYSICAL line 42



Assuming the XX..XX block is resolved first, then TRACK should (logically!) inherit this situation:

- top of page is line number 3

- cursor is on data line 44 column <whatever>, which is now PHYSICAL line 33



FIND executes and jumps to a new page, positions cursor, etc etc.

User presses the (TRACK) key and

- top of page is back on line number 3.

- lines 10 to 19 are replaced by a single '---<00010>--- ' marker line, as expected.

- cursor is on line number 53 column <whatever>

So the column is correct but the line is offset by the 10 excluded lines. In short, the cursor is on PHYSICAL line 42, as before.

Maybe(!) TRACKing the cursor line the same way you track the ToP line would help?



As I said, this is very tricky with one block of execuded lines, let alone if several separate excluded lines are present.

I haven't tested I, N, R, D, etc line cmds because they change the data as well as the display, whilst X is unique in only changing the display.

I wouldn't blame you if you just 'shrug shoulders'!

Afterall, the user knows that they entered line commands that changed the distance between Top of Page and the cursor's position.



You are correct, and after going through the various schemes I tried in getting this to work, I don't think I can correct it.
Explanation:

The TOS Track point ID is stored with the text line, as you found with BM, you can't just save a LPtr.

The Row/Col are saved in the Track stack. They can't be stored with the Track ID in the text line because multple Track Points can be created on the same page, and they all reference the same Track ID stored in the TOS line data.

So the row/col are indeed physical references.  To correct this would mean reviewing all XX/SHOW type changes to the Xclude line state, all insertions or removals of special lines (Cols, MASK, BNDS etc.) and then determining whether there are Track Stack items with Line/Row/Column references that are affected and must therefor be adjusted.  My head hurts just thinking about it.

So - - - if a user does any of those actions that insert/delete/move lines around between the creation of the Track Pointer and the TRACK/TRACKF request, the row/cols will be off.

If you're a purist and say "Well that's not acceptable, it must be corrected" then I will say "Then don't use TRACK". There is simply no 'lightbulb' moment where a nice 5 line solution will pop into my head.

I've made a few corrections based on your comments, a new Beta will show up.


George

For what it's worth...

As you say, you're returning to the/a previous PAGE not a previous position.

I found it odd anyway when doing a FIND ABC followed by RFINDs where ABC occurs several times on the same page, that a subsequent (TRACK) would jump the cursor back up the page.
I hadn't expected (TRACK) to 'remember' all those positions because we never left the page.

If somehow the Top of Page line had been excluded, you could make it visible or (perhaps more consistently) simply use the line which is the nearest previous visible line as top of page instead. If none, then use Top of Data line.
That's pretty similar to the behaviour the user 'knows' from the NX command too.
Come to think of it, that approach might also work well in many cases where the actual line Top-of-Page line no longer exists, but you would need to save the LINE NUMBER (or POINTER) along with the line marker so you know (roughly) where in the file the lost line used to be. Perhaps a bit too much effort for too little return.