|
Post by Stefan on Aug 21, 2020 3:04:04 GMT -5
Hi George,
Initial testing with version 2.2.20233 and "Reset Screen position after Line Cmds" enabled comes VERY close to the ideal. The scrolling is perfect - the screen page doesn't change. However, the cursor positioning needs a bit of tweaking. There are two aspects to this....
(1) If you simply press <ENTER> (by itself or to commit a change to a line) The 'normal' effect is that the cursor moves from the current line to the first non-blank char in the next line. (Optionally, for bonus points, if the that line is blank, the cursor placement should maintain the current indentation level of the previous or following line).
However, with the "Reset..." option enabled, the cursor remains wherever it was at the time <ENTER> was pressed. I think the cursor should still exhibit the 'normal' behaviour.
(2) If you enter a line command ON THE CURRENT SCREEN/PAGE and that line command usefully places the cursor (example I-nsert), such cursor placement is also overruled. I think in this case, the usual line command cursor logic should apply.
Hence I think we need something like the following pseudo-code logic to position the cursor
CurAttnLine = the line content where the cursor is at ATTENTION time
CursorPos = -1,-1 /* Some 'as yet unknown' row,col value */
FOR EACH line-command EXECUTE line-command IF line-command implies cursor positioning THEN /* example: I-nsert (but not N-ewline) */
IF Reset-Option is FALSE OR line-command is on current page THEN
CursorPos = Line,Col as set by line-command
ENDIF
ENDIF NEXT line-command
IF CursorPos = -1,-1 THEN /* Nothing set so use Default/'normal' */
csrLptr = Get_Next_LPtr(CurAttnLine,+1,"DATA") /* Place cursor on next line */ linData = Get_Line$(csrLptr) /* Check indent on cursor line */ csrCol = Verify(linData," ") /* Find first non-blank char or 0 */ IF csrCol = 0 AND csrLptr > 2 THEN /* If line is blank ... */ newLptr = Get_Next_LPtr(csrLptr,-1,"DATA") /* ... try the previous line */ linData = Get_Line$(newLptr) csrCol = Verify(linData," ") ENDIF IF csrCol = 0 AND csrLptr < Get_Last_Lptr - 1 THEN /* If prev line was blank too... */ newLptr = Get_Next_LPtr(csrLptr,+1,"DATA") /* ... try the following line */ linData = Get_Line$(newLptr) csrCol = Verify(linData," ") ENDIF
CursorPos = csrLptr,MAX(csrCol,1) /* Cursor Row & Col established */ ENDIF
Set_Csr(CursorPos) /* Place cursor as required */
Might I suggest that "Retain Screen position after line Cmds" is a more informative explanation?
|
|
|
Post by George on Aug 21, 2020 11:32:20 GMT -5
MUEH: OK, I'll go back again and see what I can do.
George
[Update]
OK, fixed, it was a Duh! error.
[\Update]
|
|
|
Post by George on Aug 21, 2020 11:50:12 GMT -5
Stefan:
1. (Enter) key positioning is unfortunately done even earlier than Line Cmd processing (after all, it's what starts the whole process off). So it gets 'thrown away' just like the Line Cmd positioning. And that ain't gonna change.
At the point the Attention location is saved, the positioning done by (Enter) and the LCmds has already been filtered down to a 'winner' and there's no way to determine if that winner was (Enter) or an LCmd.
2. Trying to figure out whether any of the line commands were performed 'on the current page' is also a no-go. The line command data structures, don't exist any more. The LCmd structures are iteratively deleted as they are executed (part of the convoluted LCmd logic).
Really, there's only so much that can be done to simultaneously ignore what cursor positioning LCmds have done, and then to also incorporate what they've done into a final cursor positioning.
George
|
|
|
Post by Stefan on Aug 23, 2020 11:36:57 GMT -5
Hi George,
I was afraid it wouldn't be this easy. This is clearly a tricky area and the benefits are relatively slim for the effort involved. But other members thought the idea had merit.
At the point the Attention location is saved, the positioning done by (Enter) and the LCmds has already been filtered down to a 'winner' and there's no way to determine if that winner was (Enter) or an LCmd.
That's fair enough - I accept that we cannot tell which 'component' is responsible for 'the winner' and that we cannot tell whether a given LCmd is on the CURRENT page or not.
(Although, assuming Top of Page line was captured at ATTN, "IF LCmd_LineNo < ToPg_LineNo THEN..." seems like possible test, especially if the 'winner' evaluation and LCmd execution processing are separate.)
I'm not clear of the implication of "...the point the Attention location is saved..." which is why what follows may be completely illogical. (Apologies in advance)
Questions:
(1) What's the 'winner' evaluation sequence? Does the code set the default/normal (e.g. first non-blank on next line down) and then the LCmds 'overrule' that?
(2) What constitutes 'the winner'? Is the winner the LCmd which will place the cursor, or is it held as values of some cursor row+col variable? (3) What actually places the cursor? Is it the 'winning' Lcmd when it is processed, or is it a separate instruction once all LCmds have been processed, using that cursor row+col variable?
If the 'Reset...Lcmd' Option is set, the cursor positioning 'should' be simpler than if the Option is not set.
Effectively, the Option flag could suppress all decisions regarding cursor position by LCmds and let the 'normal' (eg. At first non-blank on the next line down) positioning logic be "the winner".
This is the same as when the user entered no LCmds in the current interaction.
The issue might be that when LCmds ARE ABSENT, the default 'normal' cursor position is valid, but in the case of the Option flag suppressing the decision, the initial value may no longer be correct because the LCmds may have added or deleted lines.
But then again, the latest code version does leave the cursor exactly where it was at ATTN time, it just doesn't advance it to the next line. So maybe this isn't a problem.
Potentially, this might be solved...
EITHER by
repeating the default <ENTER> positioning logic AFTER LCmds processing has concluded WHEN the 'Reset...LCmd" Option is set
OR by changing the initial evaluation sequence from
1) Set the normal <ENTER> cursor positioning
2) Allow 'winner process' to overrule that default for LCmds
to
(1) Set a 'cursor unclaimed' indicator
(2) Allow 'winner process' to proceed for LCmds as usual - when "Reset...Lcmd" option is UNSET, the winner 'claims' the cursor and does his 'thing' as usual.
- when "Reset...Lcmd" option is SET, the winner does 'NOT claim' the cursor but still does his 'thing' as usual.
(3) If indicator still shows 'cursor unclaimed', perform default positioning logic
Grasping at straws and hoping for indulgence.
|
|
|
Post by George on Aug 23, 2020 15:34:47 GMT -5
Stefan: I'll go back again and see if there's something which can be done. George [Update] Never say I don't like a challenge. Try this version out. [\UPDATE] SPFLite22.exe (479 KB)
|
|
|
Post by Stefan on Aug 25, 2020 7:26:34 GMT -5
Hi George Initial v2.2.20237 testing reveals good progress over v2.2.20233.
1) Avoid scrolling to earlier line commands - Check 2) Place cursor on 1st non-blank of next line - Check 3) Don't override LCmds cursor placement when on current page - Check
In case of point (3), cursor positioning is different to when the "Reset...LCmds" option is UNSET. The general trend appears to be: If line command 'inserts' one or more lines (I, N, TS, C+A, M+A) - If cursor was in line number field, it moves to text area of the SAME line. It probably should move to first 'inserted' line.
- If cursor was in the text area, it moves to the text area of the next line BEFORE the line is 'inserted'. It probably should move to the first inserted line, ie. AFTER line was 'inserted'.
If line command is a 'destination' (A, B)
- Leave the cursor at the 1st non-blank char on the A/B-line, regardless of where the cursor was when <ENTER> was pressed. At the moment, if you select the destination line BEFORE the source line and press <ENTER>, the cursor sticks with the source line.
Demonstrate the above using this example data. (Each example starts from this default position)
000001 One
000002 Two 000003 Three
000004 Four 000005 Five
Enter "I" on line 3 with cursor still in line number field. <ENTER> leaves cursor under the 'T' of "Three", not on the inserted line.
Enter "I" on line 3 with cursor somewhere in the text area of that line, e.g. under 'r' of "Three". <ENTER> places cursor under the 'F' of "Four", i.e below the inserted line. Enter "A" on line 1, then "C" on line 4, with cursor still in line number field. <ENTER> leaves cursor under "F" of "Four" (now on line 5) Enter "A" on line 1, then "C" on line 4, with cursor somewhere in the text area of that line. <ENTER> leaves cursor under "F" of "Fiver" (now on line 6) Enter "TS" on line 2, with cursor under the '"o" of "Two", leaves cursor under the "T" of "Three"
4) FIND and RFIND: Are using confused positioning and search logic.
Add line 000006 Three to the sample data
Type FIND three <ENTER> ===> Cursor on line 3, word "Three"
PFK5 (Rfind) ===> Cursor on line 6, word "Three" PFK5 again ===> Cursor on Command line and Message: "Bottom of data reached"
PFK5 again ===> Cursor is now 'nailed' to line 6. Even if you RFIND or enter FIND ONE. Cursor remains in various columns of line 6
You've done amazing things already. I hope the hiccups that remain are trivial to eradicate. Once again Huge Thanks for persevering in this quest.
|
|
|
Post by George on Aug 25, 2020 8:55:12 GMT -5
Stefan: OK, my solution method fails badly. Back to the drawing board. I'm getting the feeling this is insoluble, sorry. George [UPDATE] OK, reviewed this and we're basically screwed. e.g. You do an I line command (or R, N etc.), it sets the positioning correctly to the next (inserted) line, then Attention Positioning jumps in and throws that positioning away and keeps the screen from moving, then we want to somehow resurrect the positioning I did (which is in the logical garbage bin). This is not just trying to repeat what (Enter) did for positioning, it would require a significant change to the whole way competing requests for positioning are handled, and maybe a bit of time travel as well. Sorry, but this is as far as I'll take this journey. My inclination is to yank the whole thing. [\UPDATE] [UPDATE] OK, guaranteed this is the last gasp. If the attached version is not suitable, then the whole attempt will be withdrawn. It's better, but still not perfect. [\UPDATE] SPFLite22.exe (478.5 KB)
|
|
|
Post by Stefan on Aug 29, 2020 4:07:48 GMT -5
Hi George,
Apologies for the 3 day delay - I'm redecorating the 'computer room' and had to dismantle the whole caboodle. (Notes to self: (1) Do you really need all this stuff?, (2) Hang on to this woman, her tolerance and patience is unrivaled)
Version v2.2.20240: Amazing work! All the previously noted discrepancies are gone. I'll move on to some regression testing & check some more commands. Will try to hurry this up so you don't have to retrofit many other changes to this version if you subsequently decide to keep these changes after all.
Thank you.
|
|
|
Post by George on Aug 29, 2020 8:53:12 GMT -5
Stefan: Thanks. There is still a positioning error in TOS when there are Inserts/Deletes 'up above', but generally the screen stays where it was and the actual cursor appears fine (I think).
George
|
|
|
Post by George on Aug 29, 2020 12:09:30 GMT -5
Robert: I'm mostly like you, years of pretty unstable mainframes (in the early days of TSO) we got in the habit of hitting Enter often, as that committed your entry, and even if the system went down, edit Recovery would get back your session.
With SPFLite and the ability to enter commands and then scroll around, enter more commands and then eventually press Enter/PFK, there's far more opportunity for incorrect (in the user's mind) positioning. Looking into this just reminded me of just how complicated positioning has become over the years as we tried to respond to users suggestions and niggles.
|
|
|
Post by George on Aug 29, 2020 14:39:52 GMT -5
Yeah, but if I had to choose ISPF or SPFLite -- no contest. ISPF hasn't evolved at all since I retired, and that's almost 20 years ago now. The term abandonware comes to mind. But then, the mainframe era is long gone, why invest in it.
|
|
|
Post by Stefan on Aug 30, 2020 4:01:57 GMT -5
Interesting discussion, boys, but it's basically a reflection of proprietary vs open architectures.
Back in the 60s & 70s every computer (read mainframe) manufacturer did their own thing in their own way. None was particularly compatible with any other, often not even with other kit from the same manufacturer. IBM was the same, only ultimately more successful, at least in part because they realised earlier than most that to sell hardware you MUST make it easy for customers to move to the next model range (hence S/360 architecture). So the first commandment of all software and hardware was backward compatibility to avoid folks having to change all their apps and retrain their staff every couple of years. From IBM's business perspective, such a proprietary technology 'growth' path was good because it kept customers onside. Leaving the IBM world meant big changes (read costs and risk) to their business.
Personally, I prefer a more open approach to the proprietary path. That's why I'm with Windows rather than buried in the Apple ecosystem. But there's no denying that 'proprietary' is easier for a vendor to develop and control, and for users to deploy - as long as you don't need anything outside that ecosystem.
You must have seen something good in SPF, later ISPF/PDF, else SPFLite wouldn't look the way it does. And whjle greatly enhancing SPFLite for today's needs, you have preserved the 'backward compatibility' idea, both in terms of functionality and user training requirement.
As for the subject of this thread, I'm not looking to drag SPFLite back to the 3270 world. Quite the contrary in fact. I'm enjoying the freedom of being able to work on the whole document/program/file at once, and would prefer it if SPFLite didn't drag me (via screen and cursor placement) back in time (and file location) to a 50-year old 3270 display restriction.
|
|
|
Post by Stefan on Aug 30, 2020 4:28:41 GMT -5
Stefan: Thanks. There is still a positioning error in TOS when there are Inserts/Deletes 'up above', but generally the screen stays where it was and the actual cursor appears fine (I think). George
Hi George,
Yes I noticed that the "Top of Screen" and "Cursor Positioning" changes v20237 are not any more in the v2.2.20240.
That's especially confusing when a user adds or removes deletes half a page or more of lines earlier in the file before pressing ENTER and the cursor appears half way down a completely different page. Easily done, for example by Moving a section of code down the file or Copying a section of data After any line above the current top of page.
If it's too hard to to retain it, don't worry.
In terms of additional testing....
- I assume I need not test any cursor positioning by primary commands, given that they won't have changed and in any case execute after the Line Commands?
- Do I need to test the use of Line commands from withing Macros to ensure that cursor positioining and variables such as .ZCSR operate the same with and without the 'Reset....LCmds' Option set?
|
|
|
Post by George on Aug 30, 2020 11:55:28 GMT -5
Stefan: Yes large Inserts/Deletes above the 'current' screen mess things up, and I'm afraid that's the way it stays. As to Primary commands, I agree, I don't see that needs testing. As for line macros, might be worth it, they are executed prior to regular line commands. They should also be ignored.
George
|
|
|
Post by George on Aug 31, 2020 8:57:54 GMT -5
Robert: As I said to Stefan - if this "as it stands" is not acceptable to him, I'll just yank the whole thing. No more fiddling, I've already tried 3 approaches. As you know, this area is ridiculously convoluted.
George
|
|