oldie
New Member
Posts: 2
|
Post by oldie on Aug 12, 2023 9:47:28 GMT -5
Hello, I just tried to delete the first 100 line in a file with 200 lines: ****** *********************
DD Line001
000002 Line002
... 000099 Line099
DD Line100
000101 Line101
...
the result: ...
000099 Line199 000100 Line200
****** *********************
I expect that the new position after delete is at line 000001 Line101. This works as expected if both DD block statements are on the same page on the screen.
|
|
|
Post by Robert on Aug 12, 2023 10:31:58 GMT -5
I was able to replicate this. If I put DD on line 1, then go to line 100 and put the other DD, it does what you say. If I do it in the reverse order and put DD on line 1 last, it positions the file at the beginning where "Line101" is.
If I issue a primary command DEL .1 .100 the line with "Line101" is on top and the cursor remains in the primary command line area.
I believe the issue is that there is no precise definition of where the current location should be after a line delete.
If you work with SPFLite for a while, you will find that there are a number of positioning anomalies. Some of the more annoying ones have been addressed over time. Recently, George has made an effort to minimize this.
Try this:
1. Issue the primary option command OPT GEN
That will bring up the General Options GUI
2. In the right-hand column of check-boxes, look for the box with the label, "Maintain screen position after Line Cmds".
3. Ensure the box is enabled, then click on Done.
4. Try your test again.
R
|
|
oldie
New Member
Posts: 2
|
Post by oldie on Aug 12, 2023 11:11:04 GMT -5
Thanks "R" that helped! No clue why this an option, is there any use case for not maintaining the position? If you delete without this option in a much larger file you end up in "somewhere" in you file.
|
|
|
Post by Robert on Aug 12, 2023 11:32:28 GMT -5
The REAL oldies around here know that I am Robert. I am also lazy, hence the R.
Why is this an option and not the default? I believe the rationale George used is that if the new positioning algorithm malfunctioned or didn't position "as advertised" some people's macros might not keep working. "Out of an abundance of caution" as politicians and lawyers say, it's left as an option.
Personally, my own SPFLite had this flag disabled. Now that you asked about it, I set my own flag on. I will keep an eye on it and see if it has any adverse affects. If so, I'll drop a note here.
P.S. For quite a while, I have had cases where I *really* wanted to 'stay' where I was after doing something.
To do this, I have Alt-2 and Alt-3 mapped to special commands. The idea is, Alt-3 (where the # sign is) makes a "note" of where I am, by placing a line label of .NOTE on the nearest line. Then, when I want to remember where I was "at" I press Alt-2 because key 2 has the "@" symbol on it.
Here are the mappings:
Alt-2 = LOCATE .NOTE TOP
Alt-3 = (CondLineNo){..NOTE}
To enter these, use the primary command KEYS Then, click on the picture for 2 key, and in the ALT line, type LOCATE .NOTE TOP
Repeat for the 3 key.
Then, click on DONE below. That's it.
R
|
|
|
Post by George on Aug 13, 2023 7:36:38 GMT -5
As Robert says, cursor positioning after commands has been, and always will be a problem. When you can have a single interaction with a mix of line commands, primary commands and macros all saying "Here! Here! Put the cursor here!" it's well nigh impossible to make everyone happy.
George
|
|