|
|
Post by Stefan on Apr 3, 2022 9:24:03 GMT -5
Please note: This thread is now redundant.
George implemented this in native SPFLITE following the discussion here. Please refer to the (Track), (TrackF) and (TrackC) keyboard primitives in the documentation.
George (et al),
While trying to enhance & re-structure my LP.MACRO, the ability to jump back to the previous location before LP executed proved a bit troublesome. So I took it offline and realised that a Bookmark capability could, relatively simply, be applied to many SPFlite commands, without the commands needing to be changed.
Why Bookmark? I find I quite often want to 'grab' a few lines of code from elsewhere in the file and insert them at my current position. The steps include some kind or FIND/LOCATE/LP etc command, maybe a bit of scrolling, then issue 'CC..CC' line command, then scroll back and type the 'A' line command. I might even remember to label (.a) my origin first and then LOCATE back, but it's still a pain.
This is version 2 and I'll happily accept suggestions and bug reports.
The principle is simple. Prefix any command, from which you may wish to return to the starting point, with BM (BM plus a blank to be precise) So FIND ABC LAST becomes BM FIND ABC LAST
There are two ways to 'automagically' achieve the prefixing.
(1) KEYMAP another ENTER key, as: (SaveCursor)(Home)(SetInsert)[BM ](RestoreInsert)(RestoreCursor)(Enter)
This works with potentially every SPFLite command or macro. I use the ENTER key by the numeric pad on my external keyboard. Note: Don't remap your normal ENTER key, or you'll bookmark everything. You can only go back one step.
(2) SET an ALIAS e.g: SET ALIAS.LOC=BM LOCATE This allows for L and LOCATE to operate as usual, but LOC would be bookmarked.
You'll also need a key that takes you back to the origin. I use SHIFT-Pause or SHIFT-Home
(3) KEYMAP a 'Go-Back' key as: (SaveCursor)(Home)(EraseEOL)[BM \](RestoreCursor)(Enter)
BM can accommodate some(!) pending line commands, so a SET PENDING.BM=Y is recommended too.
Taking the above example...
Type your favourite LOCATE/FIND/LP/whatever command on the command line and press your 'specially-created' <ENTER> key. Find the lines you want, enter the CC...CC command and press your 'specially-created' <GoBack> key. Enter the 'A' line command and press normal <ENTER> key.
George, you might even be able to integrate it into SPFLite code, in which case, great.
It would probably be slicker (e.g. need fewer line handles, provide better pending lcmd support, etc) and would not suffer from these...
...HICCUPS
 BM is a command and uses SPF_POST_DO(). As such it shows up separately in the RETRIEVE stack. Suggestion: Perhaps a SET NOCMDRETRIEVE.<name>=Y option??
Many line commands cannot be captured and replaced properly
|
|
|
|
Post by George on Apr 6, 2022 8:11:06 GMT -5
Stefan: Sorry for the delayed response.
BM is intriguing, because jumping around in the code is something I'm sure we all do, all the time.
I have a gleam of an idea, but it will take some experimenting to see if it's even possible.
George
|
|
|
|
Post by George on Apr 6, 2022 15:12:56 GMT -5
Robert: Stefan:
OK, I've been playing with my BM idea. What I was after was a more automated, less manual approach. So here it is:
Forget BookMarks, think BreadCrumbs.
As we move around a file, the various commands that move us around (FIND, CHANGE, LOCATE etc.) will create a BreadCrumb stack of "where we came from". This happens whether you ask for it or not.
BreadCrumbs are not created by normal Scrolling, PageUp/Dn etc. type commands. They are not created for small movements, like repetitive RFIND/RCHANGE, unless the Top-of-screen moves.
A new KB primitive (BCBak) takes you back to the latest "where you came from". Repeat and you go back further, etc.
If you 'go back' and then issue a new movement command, the current location becomes the new 'current' or top-of-stack.
Not sure if we'd need a (BCFwd) to handle the "Oops, went too far back scenario"
OK then:
How big a stack? My feeling is about 10, I can't picture going back further.
What commands should create BreadCrumbs. Right now I have LOCATE, FIND, RFIND, CHANGE, RCHANGE, NFIND, RNFIND. What other commands should be treated the same.
I attempted to make the stack Global (i.e. allow tab switching as well, but this failed miserably, I disappeared down the rabbit hole. So don't ask for that, what I have is localized to a single tab.
Comments?
George
|
|
|
|
Post by Stefan on Apr 7, 2022 2:57:52 GMT -5
George, That sounds really (and I mean REALLY) good. My thoughts...
- For what it's worth. I discovered the following... - Neither Line Number nor Line Pointer are of any use here as both can change depending on user actions.
- Only way to get this right is to attach a marker to the line. I used line_handles but the limit is one-per-line, so it gets messy if lines already have handles. - When re-positioning, you need the 'now-current' value of the line pointer, not the pointer the 'marked' line had when you marked it. - The 'marked' line may or may not have changed its XSTATUS. You may need to place cursor differently if marked line is now in an excluded block. - In gereral, I found the biggest headache is placing the cursor & TopOfPage lines SENSIBLY when jumping back. (I'm still striggling with that, but will leave it now that you're on the job  )
- Additional commands? Yes. Some, but not all, macros would be natural candidates, eg. LP.MACRO.
You can cover this via SET variable approach like SET PENDING, e.g. something like SET BC.<macname> = Y
- Excluding line/page movements like cursor-movement-initiated scrolling or UP/DOWN cmds is OK. But the chosen primary commands (& macros) must leave a Breadcrumb BEFORE they do whatever they do.
- Keeping a separate stack for each edit tab is perfect. (A bookmark has no value when it's in the wrong book!)
- I think 10 levels is probably adequate - I doubt many (if any) of us can recall more than that many steps ago (but that may just be our ages!) If you're concerned, go for the same number of entries as can be RETRIEVEd - e.g. 50, but that's probably overkill.
- I assume the markers are 'temporary' in that they are not saved by STATE ON and do not survive a restart of SPFLite?
An argument in favour of STATE saving might be that especially when I return to edit a file some time later, jumping back & forth may remind me what I last did.
- (BCFwd) Very desirable if not essential (see also STATE comment above)
Robert,
Good ideas.
I'm aware of tags but don't consider them appropriate for general purpose bookmarking, because...
- A line can only have one tag so if a user already has tagged lines, so it gets messy - tags are rather 'in your face' and I wanted the feature to be less conspicuous/distracting, ideally invisible.
- Same is true of NOTE lines inserted in the text.
UNDO/REDO are terrible in terms of going back. the UNDO jumps back to
I think George has cracked it especially as any integrated native SPFLIte approach will be faster and more reliable than any after-market solution.
|
|
|
|
Post by George on Apr 7, 2022 8:58:14 GMT -5
Robert:
I don't like the @ prefixing either, I wanted this to occur without being pre-planned by the user.
Using SET to identify the commands has problems, mainly it assumes the command is successful and the desired movement has properly occurred. e.g. a FIND that fails to find the string, a LOCATE can't find the label. But maybe that's not a real problem, since the command would be corrected and retried. Right now the BC isn't created till the command is successful. Maybe a combo, I could add a new flag to the command table, and also allow users to use SET to add other commands or macros in addition.
Why not do it for every small movement, command, scroll, PgDn etc.?? Because then the stack gets polluted with junk entries, possibly multiple items all on the same page.
Why not do it when the top of screen changes? Because there is no single point where that occurs, in fact the TOS pointer can change multiple times in one interation.
Stack size? Like Stefan, I can't picture going back more than a couple items, and if the stack was large, as you'd like, and full of all kinds of 'movement', I'd likely have to hit (Back) multiple times and carefully look at each refreshed screen to see if "it's the one I want" - not too productive.
Remember, I'm looking for something much like your :NOTE BM solution, a quick "mark my place while I go elsewhere for a moment" and then get me back, I really do not want some new multi-level stack of edit positions and all the intricacies of moving back and forth, stack resets and management etc. I'd be perfectly happy with no stack at all, just a simple, one entry 'go back' location. The more I think about, the more I like the single back entry approach.
George
|
|
|
|
Post by Stefan on Apr 7, 2022 9:18:53 GMT -5
It's possible to use line handles instead of labels. Handles are only used in macros, and a handle can coexist with labels and tags on the same line.
Erm... that's exactly what I do use. Advantage is they're invisible. Drawback is you can still only have one handle per line.
So if a file already has handles from another macro, it gets messy when you have to share a handle and when you later try to tidy up the handles this macro is responsiible for. You don't want to remove a handle 'belonging' to another macro, and you need to cater for the event that the handle you were sharing has been removed by the other macro.
|
|
|
|
Post by Stefan on Apr 7, 2022 9:37:22 GMT -5
George, I think the user doesn't need a BC when they are just scrolling around the file. 99.9% of the time, they will know how far they came and how they can get back. It is different when a primary command is issued which has the ability to move to a totally other location in the file.
I also think that success or failure has no bearing on where a marker should be set.
Simply always try to set a marker whenever a command or macro is used whose name is enabled for BC/BM. The double entry in the trail can easily be avoided.
Don't add marker to the stack if the line at top of page is the same as before. Note: This implies that you cannot just 'mark' the cursor line, you also need to mark/track the top line on the display so you know when the 'page' has changed. No user will jump back if they're still on the same page. They'll just 'move' there.
Example: 1) User issues a FIND ABC and jumps to the other end of the document. 2) Presumably they went there for a reason so they 'do' something at that new location.
At this point, if they could
- UNDO and return to a position BEFORE (1), but they also 'undo' whatever they just did at the new location as well as whatever they did at the origin location before they jumped. - with a single-shot bookmark, they would get back to BEFORE (1) with all changes intact. - with a breadcrumb trail the same is true, but it would also cater for another use case... 1a) the location they reached wasn't the right one so they issue RFIND or maybe another FIND or LOCATE, etc A single-shot bookmark will now NOT return them to BEFORE (1) but to the position AFTER (1). A breadcrumb trail will get this right - just go back two steps.
Be that as it may, I should love to have a BC trail with a handful of steps. But I'll take a one-stop bookmark facility if that's all that can be built.
We are all perfectionists, but let's not throw out baby with the bathwater.
Just because the marker(s) are not 100% reliable in all situations, does not mean we shouldn't do it at all. I'll happily accept the occasional 'No marker found' message if it means that most of the time, I can jump back.
|
|
|
|
Post by Stefan on Apr 7, 2022 11:03:50 GMT -5
Robert, You cannot use the line Number or the line Pointer for a 'marker'. They are both transient. The Line Pointer changes whenever a 'special' line is placed/removed BEFORE the marked line (don't issue PROFILE, COLS, BNDS, EXCLUDE, NX, RESET, ... etc) The Line Number changes whenever data lines are added/deleted BEFORE the marked line. (don't issue D, R, M, C, A, B, TJ, N, I, ... etc)
The further down the file you go, the greater the probability that one or more of those things occur and the 'value' on the stack is stale. It will refer to the wrong line.
The only way to 'track' a line is to attach a 'marker' to it (label, tag, handle, something-else-yet-to-be-invented). Then you can convert that 'marker' back to THE line pointer/line number which applies to the marked line at the time you want to go back to it.
The more 'stack' entries there are, the greater the issues of 'stale' markers becomes because the user has probably made more changes to the file.
Using line-handles, I tried 'marking' the ToP line AND the cursor line. There's many reasons why these lines can change their 'attitude' to each other. Either one, both or neither could be in the same or separate exclude block(s). Even when both are visible, the 'distance' between them could be different to before, if lines have been inserted/copied-in/deleted/repeated... They may not even be on the same 'page' any more. In fact, either or both lines may have been moved to elsewhere in the file. The 'marker' will have moved with the line, but that line is now completely irrelevant for repositioning. (I think especially this last one is impractical, if not downright impossible, to cater for).
It's a very hairy area.
|
|
|
|
Post by George on Apr 7, 2022 14:41:31 GMT -5
Guys: As usual (Robert knows this well, I drive him crazy doing this) I start coding and go from there. Sorry, if you're a "plan it all out first" type personality, that's not me. I poke, prod, experiment, throw away, start over etc. etc. I find it much more rewarding. Anyway, I think I'll post a Beta (Alpha?) of where I am. - The Command table now has a flag for what commands drop a breadcrumb before executing. I'm perfectly open to suggestions as to what other commands should be added by default. Right now it's LOCATE, FIND, CHANGE, RFIND etc. etc.
- There is the ability to add Commands, or Macro names, to the breadcrumb list using SET commands. Just create an entry for BCRUMB.command = Y (I have not actually tested this, but the code is there)
- There are two new primitives (BCBAK) and (BCFWD) to invoke the back and forward through the breadcrumb list.
- There is no limit to breadcrumb entries (I did it differently, there is no stack)
- Any new command (which is flagged as dropping a breadcrumb) removes older breadcrumbs. (This support is not a general purpose 'walk me back through my screen displays' type support)
I can't stress that this is very early stuff, I really need feedback and ideas to help pin it all down. Surprisingly, the Fwd/Back aspect was the hardest part of this.
Look out for the Beta release
George
|
|
|
|
Post by George on Apr 7, 2022 15:57:13 GMT -5
Robert: I was not aware that 'breadcrumbs' had any negative connotations. It's an accepted description of following the path of a search or path to a current location.
e.g. I use DOpus for a File Manager, and they provide 'breadcrumb' style support for the 'where am I" headings on file displays. (https://www.gpsoft.com.au/help/opus11/index.html#!Documents/Breadcrumbs_Configuration.htm)
So why should we avoid using the term?
George
|
|
|
|
Post by Stefan on Apr 8, 2022 7:56:46 GMT -5
FWIW, there's children's stories where a trail of breadcrumbs is used to allow folks to find their way home. Seems appropriate to me.
|
|
|
|
Post by George on Apr 8, 2022 9:52:14 GMT -5
Robert: Sorry, but breadcrumbs is a perfectly normal term. My mention of DOpus was just as an example, as they use the term in their layout preferences setup. I certainly wasn't expecting our users to even know what DOpus was. (Other than a great File Manager), nor was I trying to use DOpus as some kind of justification.
Regardless, I seriously doubt ANY user would be confused by the term. It stays.
George
References:
Dictionary.com
Usually breadcrumbs. Also called breadcrumb trail .Digital Technology. a sequence of text links on the current page of a website or web-based application, usually at the top, showing the page's location within a hierarchy of content or browsing history and providing a convenient navigational tool:
Online shoppers can use breadcrumbs to see other products in the same category.
Collins
computing
a heading that forms part of a breadcrumb trail
Wikipedia
(A snippet from their long description)
A breadcrumb trail or path based on viewing history
Lexico.com
Origin of Breadcrumbs
Mid 18th century from bread + crumb. breadcrumb (sense 2) is from the traditional story of Hansel and Gretel, who leave a trail of breadcrumbs behind them as they walk through a forest, intending to use them in order to retrace their steps.
|
|
|
|
Post by Stefan on Apr 10, 2022 4:10:29 GMT -5
Guys: As usual (Robert knows this well, I drive him crazy doing this) I start coding and go from there. Sorry, if you're a "plan it all out first" type personality, that's not me. I poke, prod, experiment, throw away, start over etc. etc. I find it much more rewarding. Anyway, I think I'll post a Beta (Alpha?) of where I am. - The Command table now has a flag for what commands drop a breadcrumb before executing. I'm perfectly open to suggestions as to what other commands should be added by default. Right now it's LOCATE, FIND, CHANGE, RFIND etc. etc.
- There is the ability to add Commands, or Macro names, to the breadcrumb list using SET commands. Just create an entry for BCRUMB.command = Y (I have not actually tested this, but the code is there)
- There are two new primitives (BCBAK) and (BCFWD) to invoke the back and forward through the breadcrumb list.
- There is no limit to breadcrumb entries (I did it differently, there is no stack)
- Any new command (which is flagged as dropping a breadcrumb) removes older breadcrumbs. (This support is not a general purpose 'walk me back through my screen displays' type support)
I can't stress that this is very early stuff, I really need feedback and ideas to help pin it all down. Surprisingly, the Fwd/Back aspect was the hardest part of this.
Look out for the Beta release
George
Hi George,
We have visitors this weekend so my testing time is curtailed. I have had one quick go. Without knowing when you capture what, and how long it stays around, it is difficult to be sure of the observations. Following was done using a window size which displays 60 data lines on each 'page', including the "Top Of Data" line
Jumping back to the previous top of page page appears to work, but cursor position is incorrect.
Example (1)
Top of page is line 0 '*** Top of data ***
Cursor is on command line
1. FIND XXX <Enter>
Top of Page is line 74 < Note. Page changes as target is 'off page' Distance from Top to cursor line is 1 line
Cursor is on line 75, col 12 ' CALL Set_XXX(...
2. (BCBAK)
Top of page is line 0 '*** Top of data ***
Cursor is on line 1, col 12 ' LP.MACRO
3. (BCBAK)
does nothing
Example (2)
Top of page is line 0 '*** Top of data ***
Cursor is on command line
1. FIND XXX <Enter>
Top of Page is line 74
Cursor is on line 75, col 12 ' CALL Set_XXX(...
2. RFIND
Top of Page is line 74 < Note. No page movement as target is on same 'page' Distance from Top to cursor line is 15 lines
Cursor is on line 89, col 15 ' CALL Set_XXX(...
3. (BCBAK)
Top of page is line 0 '*** Top of data ***
Cursor is on line 15, col 15 ' irrelevant text
Conclusion:
If a beadcrumbed command is issued with cursor on the command line, and then (BCBAK) is issued, the cursor is remains in the same PHYSICAL positon of the screen, where the command (FIND/RFIND) left it.
Apologies, I've not had an opportunity to test w=ith cursor withion the data area when breadcrumbed command is issued. Technically, because RFIND is initiated via a PFKey, it does this, but it looks like RFIND is not a breadcrumbed command, else the (BCBAK) in Example 2 would have left the screen where it was. I've also not yet had a change to test what effect 'special' lines and 'exccluded lines' would have on the process.
|
|
|
|
Post by George on Apr 10, 2022 10:57:04 GMT -5
Stefan: Right now the support ignores cursor positioning, I'm trying to first get the BC dropping and retrievel working. And that is not doing too well, like you, my testing time has been limited. RFIND is certainly supposed to drop BC.
Hopefully I'll get some time today.
George
|
|
|
|
Post by George on Apr 10, 2022 14:06:30 GMT -5
Stefan: A much improved version 22100a was posted, which now has cursor positioning, along with some rather basic functionality corrected.
George
|
|
BM is a command and uses SPF_POST_DO(). As such it shows up separately in the RETRIEVE stack.
) 