Post by Stefan on Feb 27, 2023 4:59:54 GMT -5
George,
I appreciate that UNDO/REDO works on the basis of a "at-last-ATTN-event snapshot".
As it stands, any UNDO (or REDO) command issued some time later has no knowledge of what command (if any!) made each change.
As it stands, any UNDO (or REDO) command issued some time later has no knowledge of what command (if any!) made each change.
Indeed there may not be a primary command for some 'snapshots' if the user modified the file and just pressed an ATTN key (Enter, Scroll, etc, etc) and/or used one or more line commands.
I got myself into a right muddle with UNDO/REDO which lead me to scrap the edit session and reload the file to start afresh.
The current "... n remaining" message doesn't help much when you go back several several steps.
The user may 'know' they want go back 3 primary commands, but won't have counted any other ATTN events generated since then.
So some kind of ability to see the 'command/event' list would be desirable.
If it were possible to attach the command (or a pseudo-command like 'ENTER', 'LINECMD', etc) to the 'snapshot' or maintain it in an associated list, UNDO/REDO could then...
EITHER report the command it has just UNDOne/REDOne, (tricky given width of the screen and the possible length of the 'message' field)
OR allow the command to be displayed by a HELP command immediately following the UNDO/REDO (e.g.: 'multiple messages issued - press help to see them')
AND/OR have an operand called LIST which would display the current available UNDO/REDO 'stack' and the ATTN event which generated each one (some indication of where we are in the list would be helpful)
As always, I'll leave it to your judgment as how do-able this might be.
