Post by TheFeDuke on Feb 14, 2016 1:33:45 GMT -5
"In the good old days", I could I could enter long sequences of line commands that traversed pages, and they would be preserved until the last open block and destination was complete. After that, all were acted upon.
When I noticed, that under certain circumstances, the 'D' line commands were reset with no action, I wondered if I were seeing a bug or a feature. I could digest a policy of safety "for my own good" with minor resentment, but recently I have seen inconsistencies and noted that the behavior includes the 'X' line command which is too harmless to need protection. After all, SPFLite doesn't flag an error for showing an already visible line. No point.
Before I illustrate some examples, there is an error in placing copied lines to an excluded destination line. Both 'A' and 'B' line destinations are acted upon as 'B'.
Starting with inline text:
If, in the above example, the screen is completed by a 'cut' or 'paste' primary EDIT command before pressing the action key, the cut or paste is completed and again the 'x' commands disappear with no action.
It is intuitive for me to enter a few line commands and press 'PF12' to retrieve a primary command to complete a sequence. Oops, my keystrokes are lost. This behavior is the same for the 'D' line command.
When I mentioned inconsistencies before I meant the action on the following screen, which includes 'x' and 'd' :
I think I got all of what was bothering me.
When I noticed, that under certain circumstances, the 'D' line commands were reset with no action, I wondered if I were seeing a bug or a feature. I could digest a policy of safety "for my own good" with minor resentment, but recently I have seen inconsistencies and noted that the behavior includes the 'X' line command which is too harmless to need protection. After all, SPFLite doesn't flag an error for showing an already visible line. No point.
Before I illustrate some examples, there is an error in placing copied lines to an excluded destination line. Both 'A' and 'B' line destinations are acted upon as 'B'.
Starting with inline text:
Command > Scroll > CSR
Pending Source line range command
****** ******* Top of Data *********
000001 xxx
x aaa
x bbb
000004 ccc
A xxx
000006 ccc
000007 ddd
xx xxx
xx xxx
000010 ccc
000011 xxx
****** ****** Bottom of Data *******
This preserved the 'A ' but none of the 'x' commands. I would have expected that the 'x' would be acted upon or preserved until the error is resolved. The same is true if the incomplete command is a 'C'.If, in the above example, the screen is completed by a 'cut' or 'paste' primary EDIT command before pressing the action key, the cut or paste is completed and again the 'x' commands disappear with no action.
It is intuitive for me to enter a few line commands and press 'PF12' to retrieve a primary command to complete a sequence. Oops, my keystrokes are lost. This behavior is the same for the 'D' line command.
When I mentioned inconsistencies before I meant the action on the following screen, which includes 'x' and 'd' :
Command > Scroll > CSR
****** *********************** Top of Data ************************
xx xxx
000002 aaa
000003 bbb
xx ccc
000005 xxx
mm ccc
mm ddd
dd xxx
dd xxx
d ccc
A xxx
****** ********************** Bottom of Data ********************** results in: Command > Scroll > CSR
****** *********************** Top of Data ************************
------ ------------------------------------------ < 000004 > ------
000005 xxx
000006 xxx
000007 ccc
000008 ddd
****** ********************** Bottom of Data **********************
These results are exactly what I expected and what I expected when the source or destination was a primary command.I think I got all of what was bothering me.
