|
Post by mueh on Apr 11, 2022 13:35:55 GMT -5
George: Installed 22101 and tested BCBak . If there are multiple matches of found string on screen the cursor is not positioned to previous match . e22100 (1.34 KB) do a f FOUND and RFIND in file untill you reach the end . doing now BCBak's you will see that when line 421 and 456 are on screen that cursor is not set to line 421 . Similar Problem when doing BCFwd after line 361 . Screen with cursor on line 456 is shown after 2'nd BCFwd . What do you think about RESET BC cmd to clear table ? Thanks for this feature .
|
|
|
Post by George on Apr 11, 2022 13:50:12 GMT -5
Robert: I really question whether 'readability' is important for things like KB primitives, but yes, my choices are not as readable as the majority of primitives. So TRACK/TRACKF it will be. Sometime your persistence pays off.
Actually, today I've finally, after the 3rd or 4th retry, gotten the silly functions to work correctly.
So todays Beta 20101a will have TRACK/TRACKF and the working code in it. Be assured though that all internal code and comments are fully "breadcrumb'ed".
George
|
|
|
Post by Stefan on Apr 12, 2022 3:23:10 GMT -5
Hi George, Some comments on the content of the TRACK.DOC file (I've not tested the latest beta yet)... - Looks very comprehensive.
- A list of which primary commands are TRACKed, or, if shorter, a list of which are not TRACKed would be useful. Alternatively, this could be added to each primary command's documenation entry.
- What do you think of a new macro function, e.g. Get_Track_LPtr, which returns the info for the most recent entry in the track history?
Maybe even Get_Track_Lptr(n) where 'n' is the number of steps back, but we probably only really need the most recent entry. This avoids the need for a SPF_POST_DO if the macro 'decided' it needs to return, given TRACKing is implemented via keyboard primitives.
- I agree with mueh that a RESET TRACK option to clear the 'history' would also be useful.
Probably include the TRACK option in a RESET ALL, but exclude it from 'RESET without operands'.
|
|
|
Post by George on Apr 12, 2022 9:46:03 GMT -5
Stefan: a new macro call is appropriate, with no operand meaning latest (1), or a number indicating the desired entry. With 3 values to return, I'd suggest a CSV string. E. G. xxx,yyy,zzz with xxx=TOS, yyy=screen row, and zzz=screen column.
The list of 'trackable' commands is short, I'll include it in the doc.
George
|
|
|
Post by Stefan on Apr 12, 2022 14:09:26 GMT -5
I guess if the keyboard primitives (TRACK) and (TRACKF) were primary commands, they could be combined, eg syntax: TRACK [ FWD ] and would then also be capable of being easily issued from a macro. As primary commands, it would probably be sensible if TRACK were exempt from RETRIEVE processing, like UP/DOWN/LEFT/RIGHT, etc are at the moment.
|
|
|
Post by George on Apr 12, 2022 15:04:25 GMT -5
Robert: When I do multiple TRACK/TRACKF the screen is not moved when when the stack is exhausted, it just 'sits' at the last actual re-position.
At MUEH's suggestion, there is now a RESET TRACK.
I've managed to add messages to TRACK/TRACKF. There are two conditions - End of stack - and - TOS screen line in the stack no longer exists.
For key assignments, we're all different. I used some Keypad keys, since I have a full keyboard, but I was thinking of some variation of PgUp/PgDn with a Ctrl or Alt key.
Still have to add Stefan's Get_Track_LPtr function for macros. I've also corrected a couple minor quirks in the BAK/FWD KB functions.
I quite like being able to 'walk back' a series of RFINDs. I can't count the number of times I've hit RFIND one too many times.
George
|
|
|
Post by George on Apr 12, 2022 15:09:29 GMT -5
At this point TRACK/TRACKF will remain as KB primitives, just like PgUp/PgDn/Tab/BTab etc. (and other 'moving the cursor' type functions). I really don't see an advantage to making them Primary commands. Am I missing something? What does being a primary command buy?
George
|
|
|
Post by George on Apr 13, 2022 10:46:05 GMT -5
OK, the new function Get_Track_Pos$ has been added, it returns a comma-delimited string.
TOS-Line,Screen-Row,Scrreen-Col
George
|
|
|
Post by Stefan on Apr 14, 2022 2:28:56 GMT -5
Hmm.... Happy with an expaned list of commands being TRACKed, but I'm no fan of including the 'purely positioning' commands Top/Bottom/Up/Down/Left/Right in the TRACK list. Rationale: - Most users scroll using comands AND using the mouse or cursor. Makes for inconsistent positioning as TRACK doesn't (and shouldn't) capture the latter. - SPFLite defines Up/Down/Left/Right keys by default, and many users will have defined keys for Top/Bottom as well. TRACKing these is duplication. - If I need to press TRACK several times and the check each page to see if it's the specific page I seek, I may as well just press UP/DOWN. - If TRACK records an entry for every time one of those commands is used, it will pollute the TRACK list and thus make it harder to find a 'meaningful' place to which one might wish to return.
e.g. When I read a book, I may use markers to help me find specific pages of interest, not to help me find a page 6 pages ago.
|
|
|
Post by George on Apr 14, 2022 10:55:35 GMT -5
My preference is to keep the list short, and support the SET TRACK.xxx = Y for users who want additional commands added. I agree with Stefan that the more commands that get tracked, the less useful TRACK becomes.
Frankly I'm happy with a single (or 2) stack - just get me back to where I was 10 seconds ago.
George
|
|
|
Post by George on Apr 14, 2022 15:06:19 GMT -5
Robert: Populating SET with entries, is a major piece of work. It means some special, one time code in initialization, which is already hairy. And then you get users who don't upgrade regularly and it becomes one of those "How long do we maintain the 1 time code through various upgrade versions?" Please don't go the "If you had the version level in all the CFG type entries this wouldn't be a problem ..." because you know my reaction.
I honestly can't picture anyone wanting different Tracking settings for different file types. And as for some kind of default tracking list, and some custom ones based on file types - forget it - never going to happen.
SET TRACK.name = N that's a maybe.
This is supposed to be a small additional enhancement (a couple of new KB Primitives), not a major new facility full of bells and whistles. Let's not get into the "Ooh! Then we could .... " type stuff.
Remember, I haven't packed it in yet, but I think I've earned the right to just work on things that interest me and to ignore those that don't. Take 20 years off and maybe things would be different.
George
|
|
|
Post by George on Apr 15, 2022 8:28:50 GMT -5
Robert: When this rolls out, and users start to speak up and suggest changes and/or improvements, we can re-visit it.
This is our old problem of trying to guess blind what users might want or need.
George
|
|
|
Post by George on Apr 15, 2022 14:58:17 GMT -5
Robert: Don't forget, when you enter a FIND command, the Track is created before the FIND proceeds. And at that point, where's the cursor -- the command line. So it's quite natural for a TRACK re-position to place the cursor on the command line.
There is no logic which defaults to the command line, if a TRACK cannot do the reposition, then NOTHING is done.
George
|
|
|
Post by George on Apr 16, 2022 11:18:17 GMT -5
Robert: TRACKF does not always end up back at line 1, it ends up back at the point the 1st Track was saved, which could be anywhere in the file. But that's exactly what it's supposed to do, so why is this an 'error'?
The BEFORE position is NOT meaningless. What you're asking for is the addition of an 'after' Track point to be created.
Take a 1000 line file. Manually scroll or page down to line 100, where you begin 'working'
Issue F routine-name (which happens to be at line 750. Now you do something there (Browse/Cut/Whatever) and want to go back, but don't really remember where you were when you did the F routine-name.
Now, tell me again why a a track point BEFORE the F routine-name is meaningless.
To establish 'before' and 'after' Track points, would probably require unique code within each of the movement commands and cause the elimination of adding any commands via SET TRACK.command = Y support.
I agree, probably a track point should be created when you 'arrive' at a new location, that is a non-trivial task, I'll see if I can figure some way to do it without unique command code.
And as for the 'easy-way-out' - really? The hours I've spent re-writing this 3-4 times were 'easy'?
God - I wish there was somebody brave enough to take over this thing.
George
|
|
|
Post by George on Apr 17, 2022 11:18:30 GMT -5
Robert: No need to back out. If you weren't in the background needling me to 'do it right' many of the SPFLite features simply would never have been completed.
I can be thin-skinned and overreact at times (I think this was one, I'm sorry).
Was it harder than I thought? Yes. Was I way off the mark? No, the final corrections were not extensive.
You know my style, I have no qualms about throwing out days of code and starting over (and over) till I finally get it. Could I have thought this through and got it right the first time? Even with my internals knowledge I can positively say NO. This was a 'poke and prod and see what happens' project if there ever was one. Did it end up a huge amount of code? No, surprisingly small.
We're good.
George
|
|