|
|
Post by Stefan on Sept 26, 2022 9:25:43 GMT -5
Observed using version 2.6.22217
Only just recently found the line command modifier '&'. Unlike a simple 'A' (after) line command, the 'A&' line command acts like 'A' but remains where it is, so the user can copy/move several lines 'after' the 'A-line' without needing to retype 'A' every time.
In a file like the one below, I placed the B& line command on line number 3 and then moved line numbers 9, 8, 10 and 6+7 (as a block) in that order.
000001 line one
000002 line two B& line twenty
000004 line twenty-one 000005 line twenty-two
000006 line six
000007 line seven
000008 line four
000009 line three
000010 line five
The issue is that there should only be ONE B& entry, but every time I issue a move command (M line command) I end up with B& on more lines. The moves do operate correctly in that the moved line appears in the right place, but the moved line (or the first line of the moved block) also inherits a B& line command in its new location.
|
|
|
|
Post by George on Sept 27, 2022 8:31:14 GMT -5
Odd. I'll have a look.
George
[UPDATE]
I hate to say this, but if this gets fixed (ever) it will take a long time. It is buried very deeply in the whole line command handling jungle, I'm not sure anymore how it all works. I've spent a few hours now in debug, and basically gotten nowhere. LCmd handling goes through many iterations through routines as it winnows down to what's actually needed to be done, this makes adding breakpoints ridiculous as they get hit over and over during these loops and it's easy to lose track of what level of calling you're at.
I wish I had never been talked into adding the & support, line comands were bad enough before them.
It works fine with CC instead of MM.
It works fine with A& instead of B& (Probably because the insertion point is before the B& line, but this is true for CC as well.
For now use A&. If I feel brave I might try again, but this is at the bottom of my list. I'm really concerned any fix may just open up other weird oddities in line control handling.
Maybe I'm just getting too old to wrap my mind around all this anymore.
[/UPDATE]
|
|
|
|
Post by Stefan on Sept 28, 2022 12:40:05 GMT -5
I take your point. I think the & notation is probably rarely used and B& even more rarely. So I have no issue with this being left asis. As I said, it DOES work, except for leaving the extra, let's call them ghost B& 'labels' hanging around. I note they do not cause any issue while the user is busy sending more lines to before the original target line. I wondered if it might be caused by a "double placing" of B& or maybe the display routine. I note that the ghost B& appears on the same physical line on the screen (LPTR?) which the original B& occupied, but the original has of course popped down by 1 one or more lines.
SPFLITe doesn't notice the ghosts either. The user, after finishing the move commands, removes the original B& and everything continues to work as it should. SPFLite doesn't 'see' these the ghosts. Press <ENTER> and there's no error message, scroll up/down and they remain. But enter any other line command on any line above them & press <ENTER>, and they magically disappear. |
|
|
|
Post by George on Sept 28, 2022 13:31:28 GMT -5
Stefan: Yes, they're 'ghosts'. In-process line commands are tracked in a table as they're entered. This is to avoid scanning a huge file for pending commands (think million+ lines).
As lines are inserted/deleted, this table and it's reference LPtr values has to be adjusted for these inserted/deleted lines (along with a bunch of other internal similar tables). Somewhere this adjustment for the B& style is fouled up.
I'm going to have to carefully 'walk' through the CC/B& and MM/B& variations and see if I can spot why one works and the other doeasn't. Plain old slog-work.
George
|
|
