(PA2) Primitive - INOP after (EraseEOL)

Stefan
Administrator

Posts: 990

(PA2) Primitive - INOP after (EraseEOL) Jan 4, 2024 8:29:56 GMT -5

Quote

Post by Stefan on Jan 4, 2024 8:29:56 GMT -5

George,

Version is beta v24002

I'm believe that (PA2) used to recover text lost by pressing (EraseEOL).

This is no longer the case

Does (EraseEOL) now generate an ATTN event? I can't see why it should.

The documentation refers to a 'internal RESET command', might that be the cause?

I also think (PA2) functionality does not agree with the documentation, which states...

...<snip>...

If you press the PA2 key BEFORE pressing any other Attention key (Like Enter, PFn, PgUp, PgDn etc) then PA2 will 'throw away' all your keyboard activity since the screen was last displayed.

Note: PA2 will internally do a RESET COMMAND function to clear any outstanding line commands.

As long as you press no other keys, you can repeatedly toggle PA2 to go back and forth between the original and the modified version of the screen.

If you do this Back-and-forth toggle, the reset line commands will not be restored.

So, "...then PA2 will 'throw away' all your keyboard activity since the screen was last displayed." All sounds pretty straight forward.

In the example below I am only using 'normal data entry' keys, no ATTN keys of any kind, nor any KEYMAPped keys, etc

1) Load any file

2) Type bad1 anywhere - press (PA2)

Result: All OK, bad1 vanishes, original text reappears.

Repeated (PA2) toggles between original 'view' and bad1 'view'.

3) Press (PA2) so that screen shows the original 'view'

4) Move the cursor to another line using the cursor up/down arrow key(s).

5) Type bad2 on that line - Press (PA2)

Instead of the previously restored original 'view' you get bad1 'view'. Repeated (PA2) toggles between bad1 'view' and bad2 'view'.

At this point, the, already rejected, bad1 view has become the new baseline. The original view from the last ATTN is no longer available.

Effectively you can use (PA2) only once after an ATTN event without corrupting your file with some 'bad' data you didn't mean to type.

Shouldn't (PA2) always keep the same baseline - the original screen as displayed after the last ATTN event - rather than the screen BEFORE the last (PA2) occurence?

Last Edit: Jan 4, 2024 8:32:50 GMT -5 by Stefan

George
Administrator

Posts: 4,056

(PA2) Primitive - INOP after (EraseEOL) Jan 4, 2024 10:55:58 GMT -5

Quote

Post by George on Jan 4, 2024 10:55:58 GMT -5

Stefan:
Well, this is an either/or situation.

You can have:
1: The way it is - to toggle back and forth between the before/after screen.
2: A one-shot PA2, it will restore the screen, but you lose the toggle ability.

I can not see a way to give you both.

George

Stefan
Administrator

Posts: 990

(PA2) Primitive - INOP after (EraseEOL) Jan 4, 2024 15:44:18 GMT -5

Quote

Post by Stefan on Jan 4, 2024 15:44:18 GMT -5

George,

I figure you retain two copies of the line range visible currently on the screen (or perhaps just the screen buffer),

- the original baseline, taken at the end of the ATTN event

- the current version the user is looking at - taken at the time (PA2) is pressed

Repeated presses of the (PA2) key either display the original baseline, or the current version from before the (PA2)

I think there is a way to do both, and it depends on which version the code selects as the new baseline AFTER the (PA2) key is pressed.

Consider this sequence. Note that the only ATTN event in this sequence is at step (0).

0) ATTN event occurs.
1) I'm on the original screen, the one immediately after an ATTN event - call it (A)
2) I type some bad data and change my mind - call the messy screen (B). So (B) = (A) + bad data.
3) I press (PA2) which returns me to the point before I typed the 'bad' data, so I'm back on screen (A).

At this point, if I were to press (PA2) repeatedly, the effect is to toggle between screen (A) and screen (B).

But I only pressed (PA2) once, so I "selected" screen (A) with which to continue.

Therefore, as soon as I type any key other than another (PA2), screen (B) is stale and irrelevant

(Had I pressed (PA2) twice, I would have 'selected' screen (B), and screen (A) would be stale and irrelevant)

4) I start typing again, probably some good data and then, as luck has it, some more rubbish - call this screen (C), So (C) = (A) + good & rubbish data.
5) I press (PA2) again.

    At this point I expect to be back on screen (A), because
    (a) it is the baseline established after the previous ATTN event, i.e after step (1) AND
    (b) it is also the version of the screen at which I started typing at step (4) after rejecting what I typed at step (2)

BUT instead I'm looking at screen (B) - a version of the file which was previously rejected and had be superceded by step (4).

I submit that toggling between two screens only makes sense when there are no intervening key strokes between the (PA2) key strokes.

The "toggling" key sequence must be (PA2) followed immediately by another (PA2). Any other key sequence does NOT imply a toggling event.

As soon as the user presses a different key following the (PA2) key, the code needs to decide which version of the screen to retain as the new baseline.

It can EITHER...
- replace the original baseline with the version of the screen which the most recent (PA2) key press placed on the screen - i.e. the one the user selected.

OR...

- always keep the original baseline from step(1) - i.e. as at the last ATTN event (A)

All this still leaves the question:

Why does (PA2) not restore the screen if the 'mess' was created by pressing (EraseEOL)?

I'm 98% sure, that used to work and is extremely helpful, given that (EraseEOL) has the potential to remove a lot of 'good' data in one fell swoop!

Just the sort of scenario where (PA2) is particularly desirable.

Last Edit: Jan 4, 2024 15:55:27 GMT -5 by Stefan

George
Administrator

Posts: 4,056

(PA2) Primitive - INOP after (EraseEOL) Jan 4, 2024 16:15:48 GMT -5

Quote

Post by George on Jan 4, 2024 16:15:48 GMT -5

Stefan: I'll review all the PA2 stuff again with your comments, but the (EraseEOL) is triggered by the changes for (TabBNDS), I think it now does a full refresh to get the display refreshed. I'll review that as well but getting it to work when making the (TabBNDS) changes was tricky.

There are just way too many interactions between various 'features', it's hard to touch one without mucking something else up.

George