|
|
Post by Stefan on Jan 24, 2023 6:09:31 GMT -5
George,
You've seen my code in macros so you know I tend to comment a lot of lines so the next programmer (usually older! me) can follow what's going on.
And my OCD tendencies means I like my code tidy. Hence it will come as no surprise that I value (DATAINSERT) as much, perhaps more than (INSERT) to keep comments where they are whilst changing the code on a line. Unfortunately, using different INSERT-related primitives after one another is a tad unpredictable.
Each one works perfectly by itself, but when you mix (Insert), (DataInsert) and (ResetInsert), data entry becomes like Forrest Gump's box of chocolates - "you never know what you're gonna get"
As documented, we have these primitives (DataInsert) This function will toggle Data Shift Insert Mode, comparable to the INS mode that occurs when the Insert key is pressed <= mini bug: not entirely correct, see below (Insert) Will toggle the current Insert/Overtype status (ResetInsert) Will save the current status of the keyboard Insert Mode and then turn Insert Mode OFF regardless of its current setting. (RestoreInsert) Will restore the keyboard Insert Mode to the state it had prior to a previously issued (ResetInsert) or (SetInsert).(SetInsert) Will save the current status of the keyboard Insert Mode and then turn the Insert Mode ON regardless of its current setting.
Q: What is missing? A: There is no primitive that simply turns OFF all Insert modes. (ResetInsert) replaces the current mode with the previous mode, which might be OFF or might be the opposite Insert mode. Pressing <ENTER> does turn off all Insert modes, but that's kind of disruptive while the user is typing in data to a line.
Q: What's the (DataInsert) mini-bug? A: Used by itself, the (dataInsert) key toggles (DataInsert)ON/(DataInsert)OFF. But, after the key sequence like (DataInsert)...(Insert)...(DataInsert), the (DataInsert) key toggles (Insert)ON/(DataInsert)ON/(Insert)ON/(DataInsert)ON, etc. The key now won't turn OFF either insert mode. This effect can be avoided if you switch between the two insert modes by pressing the 'current' mode key again (toggle off) BEFORE pressing the 'other' insert mode key, but who does that?
As a dyed-in-the-wool 3270 user, I 'instinctively' turn OFF insert mode by pressing the 3270-RESET key (bottom left) and have mapped as Left-CTRL as (ResetInsert) for just this purpose.
Unfortunately, that primitive sometimes "resets" the insert mode to OFF as intended, but more often than not just "switches" to the previous (other) insert mode and consequently unwanted stuff moves about on the line as I type.
Q: What is the suggestion? A: (1) Add a new primitive (e.g. UnsetInsert, InsertOff, InsAllOff... <PickYourOwn>) which just turns OFF whatever Insert mode(s) is(are) in effect, i.e the effect of the <ENTER> key, but without moving the cursor and the Attn event. (2) Fix the (DataInsert) toggle so that it ALWAYS toggles (DataInsert) mode ON/OFF as described in the documentation.
|
|
|
|
Post by George on Jan 25, 2023 10:31:03 GMT -5
Stefan: I agree it's a zoo.
My take? I think we need a (SaveInsert) and (RestoreInsert) and remove any saving and restoring from the other functions.
So we'd end up with:
(Insert) Toggle INS / OVR - Reset DataInsert - Same as now
(DataInsert) Toggle DataInsert / (INS/OVR) - Same as now
(SetInsert) Set Insert Mode - Don't save current - Remove saving current
(ResetInsert) Reset Insert Mode - Don't save current - Remove saving current
(SaveInsert) Save Insert and DataInsert modes - New primitive
(RestoreInsert) Restore saved modes - New primitive
This separates the Save/Restore functions and allows the user to choose how and where to utilize them.
Comments?
George
|
|
|
|
Post by Robert on Jan 25, 2023 10:40:01 GMT -5
The functions internally save so that you don't need a separate step to save when you later restore, because the restore function has no way to know if a prior save was done or not. The way it works now, you can safely restore without risking a "restore has no data to restore" trap. This is not a zoo. It was intentional. If you change things you will break this behavior.
As the developer, if you wish to break it, that's up to you. Be forewarned, that's all.
|
|
|
|
Post by George on Jan 25, 2023 10:56:04 GMT -5
Stefan: The (DataInsert) mini-bug. I can't follow your sequence, it seems to be working as expected.
Details?
George
|
|
|
|
Post by George on Jan 25, 2023 10:57:22 GMT -5
Robert: OK if my idea would break things, how about an idea to fix this without breaking things?
George
|
|
|
|
Post by Robert on Jan 25, 2023 12:32:16 GMT -5
The problem about changing it, is that if you're writing a keyboard macro, and you want to properly save and restore the insert state, you don't know what the prior state is.
Say you have insert OFF first, and your macro needed insert to be on.
If the macro did INSERT ON, DO SOMETHING, INSERT OFF
that would be fine. If insert were ON beforehand, the macro would "work" but now the prior ON state has be changed to OFF, when you didn't want that to happen.
The goal in all this is to prevent a macro from altering the "prior state". You want the macro to go in, "do something" and get out, without interrupting what the user was doing previously.
The design of the existing functions already does that now, and it works. You should know; YOU wrote it.
I believe it is best to avoid over-thinking this. What was the original complaint?
"There is no primitive that simply turns OFF all Insert modes."
To fix the complaint without breaking what is there:
1. Leave all existing functions alone.
2. New function: (ClearInsert)
Let (ClearInsert) clear whatever is necessary to resolve the problem.
|
|
|
|
Post by George on Jan 25, 2023 12:59:12 GMT -5
OK, a new (ClearInsert) it is, everything else stays the same to avoid 'breaking' anything currently using these primitives.
George
|
|
|
|
Post by Robert on Jan 25, 2023 14:09:17 GMT -5
I was unable to reproduce the "data insert mini bug". It does not act on my system the way Stefan claims. Instead, Data INS followed by INS shuts off Data INS and restores the state to OVR.
I was unable to perform any combination of Data INS and normal INS that caused any malfunction. AFAICT, there is no bug.
|
|
|
|
Post by Stefan on Jan 26, 2023 6:49:20 GMT -5
George, Robert,
The above sounds fine except for the mini-bug(s).
Note that my default keyboard state is OVR rather than INS - set via OPTIONS KBD, and all this applies to v23018. Hence I am wondering if this is a phenomenon that doesn't affect folks who run with INS mode as default. (I'm up to my armpits in grandchildren under 3 at the moment so my testing time is limited, and my brain is mush, so maybe you can figure out that aspect for me.)
I've done some more trials to boil this down to the simplest way to illustrate the effect. I now think there's several aspects to this: Given there is two insert modes (Insert and DataInsert) I'll talk in terms of OVR/INS/dINS
(ResetInsert) does not reliably reflect the new state in the Status Bar, so you can't tell what will happen next. e.g.
Press: (Insert) followed by (Insert) SB shows: INS OVR
Effect: INS OVR
Press (Insert) followed by (ResetInsert) followed by (Insert) SB shows: INS INS wrong INS
Effect: INS OVR INS
Press (DataInsert) followed by (ResetInsert) followed by (DataInsert)
SB shows: dINS dINS wrong dINS
Effect: dINS OVR dINS
The mini-bug:
I'm not surprised that you struggle to provoke the mini-bug. I do as well, but it is there. It seems to me that the supposed "toggle On/Off" (or INS/OVR) is in effect a "toggle ON/previous", but it may not be that simple.
Basically, if you STRICTLY only operate only one insert mode at a time, you will have no issues. So (Insert) followed by (Insert) is fine - INS mode, type something, back to OVR mode. Same for (DataInsert) followed by (DataInsert), - dINS mode, type something, back to OVR mode.
But if you mix the inserts modes WITHOUT terminating the first before starting in the second, it gets messy, probably because we're now dealing with 3 possible states, OVR, INS and dINS.
Starting in OVR mode, watch the INS/OVR flag in the Status Bar as you press this key sequences:
Press (Insert) followed by (DataInsert) followed by (DataInsert) from now on DataInsert toggles INS/dINS
SB shows: INS dINS INS wrong
Effect: INS dINS INS wrong
Why would you press (DataInsert) again if you were already in that mode?
(a) to turn it off - except it doesn't now do so.
(b) because you navigated to another part of the file, want to insert data but forgot about the current setting
Hope this helps.
I think that (Insert) and (DataInsert) should operate as follows... (Insert): If mode is not INS, switch to INS mode, else switch to OVR mode. (DataInsert) If mode is not dINS, switch to dINS mode, else switch to OVR mode. (I guess for folks with INS as default we need to reverse OVR and INS/dINS)
This would allow each key to initiate the requested insert mode and either key to be used to 'terminate' whatever insert mode is in effect.
I think you need to examine this in the light of my default of OVR to ensure it doesn't mess up users who like to run with INS as their default. Perhaps the key logic I proposed above needs to be more selective depending on which setting the user has chosen in OPTIONS - KBD.
We need to either fix (ResetInsert) so it works properly and/or add a (ClearInsert) primitve (like the name, why didn't that occur to me - mush brain!)
|
|
|
|
Post by George on Jan 26, 2023 10:14:28 GMT -5
Stefan: Robert: I tried again, but still didn't trigger the mini-bug. However, I did spot a couple functions that did NOT refresh the Status Bar. So, I've refreshed my brain by re-reading Help for all these commands. I think I will do the following: - Correct the failure to update the StatusBar in a couple places.
- Make all these functions DO exactly what they have always been documented as doing.
- (Insert) will be a simple toggle of INS/OVR. It will also clear dINS mode.
- (DataInsert will be a dIns toggle. When toggled OFF it will reset INS/OVR to the Options default for INS/OVR.
- (ClearInsert) - the new guy - will force reset to plain OVR mode.
- (SetInsert) will save the current INS/OVR setting and switch to INS mode.
- (ResetInsert) will save the current INS/OVR setting and switch to OVR mode.
- (RestoreInsert) will re-establish the saved value from the latest (SetInsert) (ReSetInsert).
There were some inconsistencies when I reviewed the various code bits. Lets get this done, test again and see where we stand. I'll try and get a Beta out.
George |
|
|
|
Post by Robert on Jan 26, 2023 12:11:40 GMT -5
All these seem reasonable changes. I do have a question about (DataInsert).
Suppose my keyboard default is OVR. Then I press the INS key and now I am in INS mode.
Now, I press the key for (DataInsert). The state is now d-INS.
If I press (DataInsert) again to disable d-INS, do I want the keyboard default OVR/INS state, or do I want the state that existed prior to doing (DataInsert) the first time?
Some these actions, if they involve restores of prior states, might imply a 'stack'. Adding stack logic complicates the behavior and is harder to document, but we DO have such behavior for (SetInsert) and (ResetInsert) vs. (RestoreInsert).
I am not advocating for you to change what you just put in the beta. Mainly, I am just asking the question, is this the correct way to do it? I am not sure myself what's right.
===> More information.
I tested again on 23.026.
If I am in d-INS mode, it doesn't matter if I then press INS or the d-INS key; either one will return me to plain OVR mode.
I am not sure if this is "correct", but one thing I *am* sure of: It's simple and easy to understand.
That in itself is probably a good argument for leaving the beta code in place, unless someone finds a bug.
|
|
|
|
Post by George on Jan 26, 2023 12:24:28 GMT -5
Robert: I had to think on that one as well. I went with the Help file that only describes saving the state for the 3 specific functions you mentioned.
There is the problem of
(SetInsert)....(DataInsert)....(RestoreInsert)
which state gets restored - the one before (SetInsert) or the one after (SetInsert) i.e. the save created by (DataInsert)
We could be trading one problem for another. Sure we could go to a stack, but since (DataInsert) is a toggle the above would still not be correct. That is, is it pushing onto the stack, or pulling off the stack?
George
|
|
|
|
Post by Robert on Jan 26, 2023 12:35:52 GMT -5
Which state gets restored? Answer: The state that was last saved.
Which state was last saved in your example? (SetInsert), because (DataInsert) doesn't save the prior state (to my knowledge; maybe I'm wrong?)
Right now, (RestoreInsert) is documented as restoring the state prior to the last (SetInsert) or (ResetInsert). Those two functions SAVE then ASSIGN the insert state, while (DataInsert) TOGGLES the d-INS state. (DataInsert) NEITHER pushes nor pops anything.
For better or worse, the existing functions were designed without a stack. If we hack them, it could break things, as per my prior warning.
If INS mode is really THAT important, a case might be made for two new functions: (PushInsert) and (PopInsert). If you wanted, you could really go crazy and parameterize these, like (PushInsert/n) where 'n' is 0 or 1 for insert-mode ON or OFF.
But, I am guessing you'd rather beat your head with a hammer than go that route.
|
|
|
|
Post by George on Jan 26, 2023 12:45:32 GMT -5
Robert: Sorry, I misinterpreted your comments as a suggestion to have (DataInsert) also perform a save.
We can leave the hammer in the toolbox.
George
|
|
|
|
Post by Stefan on Jan 26, 2023 15:17:36 GMT -5
I should like to add my vote AGAINST a stack. In a way, the mini-bug kind of acts like a stack alredy and it is VERY annoying when you think you are in one mode and then stuff shifts or is overtyped about because you're in another. That's why I suggested that turning off insert mode should go back to OVR (or default) regardless of which insert mode was active. It makes the whole thing predictable. Similary, pressing either key 'replaces whatever mode was in effect with the mode of that key. Again, that makes it all predictable.
I never use the (Insert) or (DataInsert) key to turn off the relevant mode anyway. It's just not 'natural' for me. After years with 3270s, the RESET key is bottom left and thus Left-CTRL will be mapped to (ClearInsert) when it is available. We can't drop the 'toggle' approach as some users may be used to it.
When working with code, some lines are just code, others are code followed by a comment. My comments usually start just over half way along the line, say col 55 or 60. When typing code, I use (DatatInset) if the line has a comment because otherwise the comment shifts right, possibly for no reason. If it is comment delimited at both ends e.g. /* .... */ then it is likely I need to 'correct' both bits. (I'd use a MASK for the comments, but I dislike the fact that MASK data starting in say col 50 is treated as the point where an inserted line places the cursor, so MASK is effectively unusable for me.) |
|
