Post by Robert on Jan 26, 2023 23:42:37 GMT -5
Well, after spending the evening singing karaoke, I have a fresh perspective on the INSERT MODE controversy, and I believe there is a relatively straight-forward solution.
The more this issue gets kicked around, the more a few things become clear:
1. There is an actual problem, but (so far) it's been hard to explain or quantify.
2. People keep mentioning a "stack" as a solution, but no one has explained how the problem has the attributes that warrant a stack solution. (Dealing with "nested data" like multiple nested parentheses, is the kind of clue we should be looking for, but I see no such 'clues'. That tells me that all the talk about stacks and stack solutions is wrong.)
3. The interaction of two different insert modes (regular vs. data) are giving people a brain-freeze. Somehow this is messing with our heads, and people are getting no where.
4. The risk of "breaking" things is getting larger with each new forum post. That needs to be prevented at all costs.
So, how can we resolve this dilemma? Here's my take on it.
I mentioned in a recent post that it seems like the problem is pointing to a solution where INS and Data INS need to behave independently. THAT IS EXACTLY WHAT IS NEEDED. But, how would this work, and also not 'break' anything? I believe it needs to go like this:
---
1. What do we know now? Here's the doc on Insert and DataInsert:
(Insert)
Will toggle the current Insert/Overtype status, which is displayed on the status line as INS or OVR.
(DataInsert)
This function will toggle Data Shift Insert Mode, comparable to the INS mode that occurs when the Insert key is pressed. Data Shift Insert Mode allows data to be inserted into lines in a way similar to the way that the Data Shift line command > operates. Because of this, if you are inserting data that is formatted into columns, (DataInsert) will not disturb the column alignment, as long as two or more blanks separate the columns. A suggested mapping for this key is Ctrl-Insert or Shift-Ctrl-Insert.
Data Shift Insert mode will also be reset if the normal (Insert) key is pressed.
When Data Shift Insert Mode is in effect:
•non-blanks are shifted right as new data keys (including spacebar) are pressed, as usual
•when existing non-blanks are pushed to the right, and a span of two or more blanks follows the non-blanks, the span of blanks is shortened
•a span of blanks will never be completely removed by shortening it; there will always remain at least one blank
•the status indicator will show INS instead of INS or OVR
•pressing either of the the keys mapped to (Insert) or (DataInsert) will cause the status indicator to revert from INS back to OVR
---
2. Which of these are a problem?
(a) "Data Shift Insert mode will also be reset if the normal (Insert) key is pressed."
(b) "the status indicator will show INS instead of INS or OVR"
(c) "pressing either of the the keys mapped to (Insert) or (DataInsert) will cause the status indicator to revert from INS back to OVR"
---
3. WHY are these a problem?
These keyboard functions are not "functional". That is, any time you have a "function" whose behavior must be described with an "AND", it is not a "function". A true function only does one thing.
---
4. In what sense are the Insert and DataInsert 'functions' not functional?
The problem is that (Insert) can disable the (DataInsert) and vice-versa. INSERT is a mode. If the (Insert) function were "functional", then it would ONLY affect that mode; and yet it does "more". That's bad. It's like Insert and DataInsert are "at war with each other". Because of the mutual interference of these to functions, they cannot be described in a true functional way. When that happens, bugs are sure to follow.
No wonder this things seems crazy. It is.
---
5. What's wrong with the current "status indicator"?
An "indicator" reports on a state. As in, ONE state. But what is happening is the, currently, the OVR/INS indicator is reporting on TWO states: The 'normal' OVR/INS mode, and the Data INS mode. Because of this, if we changed the semantics of the Insert functions, it is difficult to make them "functional", because right now you can't "see" both states. Example: If (Insert) and (DataInsert) worked independently, then shutting off Insert should leave Data INS alone, and yet it doesn't. But, even if it DID do that, there is no way to "see" it, because there's only one indicator on the Status Bar. That is a big part of the problem.
=============
SO HOW DO WE FIX THIS MESS?
Here is my answer. I could be wrong, of course, but I believe we need to do this.
As described in the following post, I am going to call the Data Insert mode state and indicator "DIN".
1. The INS mode and the DIN mode need to operate independently.
2. For (1) to work, the Status Bar item for INS/OVR needs to change. It should look something like this:
(a) DIN is off and INS is off:
[ OVR]
(b) if DIN if off and INS is on:
[ INS]
(c) if DIN is on and INS is off:
[ DIN OVR]
(d) DIN if on and INS is on:
[ DIN INS]
3. (Insert) and (DataInsert) will toggle each indicator independently, without reference to each other.
4. There will be new, corresponding functions for DIN that mimic what INS functions do now, but applying only to the DIN state:
(Set_DataInsert)
(Reset_DataInsert)
(Restore_DataInsert)
The logic of these functions should basically work like just their non-D versions, except they'd operate on the DIN status, not the INS status.
5. I believe the new function (ClearInsert) was probably based on a misunderstanding (admittedly, mine) and should be yanked. We don't need it.
6. SO ... how does all this fix things?
We would now have two status indicators that operate independently. When it comes time to apply them to an edit session, SPFLite would do THIS:
(a) When DIN mode is on, it TAKES PRIORITY. Regardless of the INS state, if DIN is on, the editor runs in DIN mode and implements DIN functionality, and the normal INS state would be ignored.
(b) When DIN mode is off, the regular INS state is inspected, and the editor runs in INS mode and implements INS functionality.
(c) When (a) and (b) do not apply, we are running in normal overwrite mode.
Because there would be TWO independent visual indicators, and two internal program variables that represent the states of these two indicators, and because they both are managed independently, neither can interfere with the other. So, neither can "break" the other.
We avoid "breaking" things by applying the "insert priority rules". By having two independent states, and a set of "priority rules" to coordinate them, we do not need a stack. And, viewed from the perspective of either INS or DIN , each can operate on their own, each without regard to the 'other' state.
Comments invited.
The more this issue gets kicked around, the more a few things become clear:
1. There is an actual problem, but (so far) it's been hard to explain or quantify.
2. People keep mentioning a "stack" as a solution, but no one has explained how the problem has the attributes that warrant a stack solution. (Dealing with "nested data" like multiple nested parentheses, is the kind of clue we should be looking for, but I see no such 'clues'. That tells me that all the talk about stacks and stack solutions is wrong.)
3. The interaction of two different insert modes (regular vs. data) are giving people a brain-freeze. Somehow this is messing with our heads, and people are getting no where.
4. The risk of "breaking" things is getting larger with each new forum post. That needs to be prevented at all costs.
So, how can we resolve this dilemma? Here's my take on it.
I mentioned in a recent post that it seems like the problem is pointing to a solution where INS and Data INS need to behave independently. THAT IS EXACTLY WHAT IS NEEDED. But, how would this work, and also not 'break' anything? I believe it needs to go like this:
---
1. What do we know now? Here's the doc on Insert and DataInsert:
(Insert)
Will toggle the current Insert/Overtype status, which is displayed on the status line as INS or OVR.
(DataInsert)
This function will toggle Data Shift Insert Mode, comparable to the INS mode that occurs when the Insert key is pressed. Data Shift Insert Mode allows data to be inserted into lines in a way similar to the way that the Data Shift line command > operates. Because of this, if you are inserting data that is formatted into columns, (DataInsert) will not disturb the column alignment, as long as two or more blanks separate the columns. A suggested mapping for this key is Ctrl-Insert or Shift-Ctrl-Insert.
Data Shift Insert mode will also be reset if the normal (Insert) key is pressed.
When Data Shift Insert Mode is in effect:
•non-blanks are shifted right as new data keys (including spacebar) are pressed, as usual
•when existing non-blanks are pushed to the right, and a span of two or more blanks follows the non-blanks, the span of blanks is shortened
•a span of blanks will never be completely removed by shortening it; there will always remain at least one blank
•the status indicator will show INS instead of INS or OVR
•pressing either of the the keys mapped to (Insert) or (DataInsert) will cause the status indicator to revert from INS back to OVR
---
2. Which of these are a problem?
(a) "Data Shift Insert mode will also be reset if the normal (Insert) key is pressed."
(b) "the status indicator will show INS instead of INS or OVR"
(c) "pressing either of the the keys mapped to (Insert) or (DataInsert) will cause the status indicator to revert from INS back to OVR"
---
3. WHY are these a problem?
These keyboard functions are not "functional". That is, any time you have a "function" whose behavior must be described with an "AND", it is not a "function". A true function only does one thing.
---
4. In what sense are the Insert and DataInsert 'functions' not functional?
The problem is that (Insert) can disable the (DataInsert) and vice-versa. INSERT is a mode. If the (Insert) function were "functional", then it would ONLY affect that mode; and yet it does "more". That's bad. It's like Insert and DataInsert are "at war with each other". Because of the mutual interference of these to functions, they cannot be described in a true functional way. When that happens, bugs are sure to follow.
No wonder this things seems crazy. It is.
---
5. What's wrong with the current "status indicator"?
An "indicator" reports on a state. As in, ONE state. But what is happening is the, currently, the OVR/INS indicator is reporting on TWO states: The 'normal' OVR/INS mode, and the Data INS mode. Because of this, if we changed the semantics of the Insert functions, it is difficult to make them "functional", because right now you can't "see" both states. Example: If (Insert) and (DataInsert) worked independently, then shutting off Insert should leave Data INS alone, and yet it doesn't. But, even if it DID do that, there is no way to "see" it, because there's only one indicator on the Status Bar. That is a big part of the problem.
=============
SO HOW DO WE FIX THIS MESS?
Here is my answer. I could be wrong, of course, but I believe we need to do this.
As described in the following post, I am going to call the Data Insert mode state and indicator "DIN".
1. The INS mode and the DIN mode need to operate independently.
2. For (1) to work, the Status Bar item for INS/OVR needs to change. It should look something like this:
(a) DIN is off and INS is off:
[ OVR]
(b) if DIN if off and INS is on:
[ INS]
(c) if DIN is on and INS is off:
[ DIN OVR]
(d) DIN if on and INS is on:
[ DIN INS]
3. (Insert) and (DataInsert) will toggle each indicator independently, without reference to each other.
4. There will be new, corresponding functions for DIN that mimic what INS functions do now, but applying only to the DIN state:
(Set_DataInsert)
(Reset_DataInsert)
(Restore_DataInsert)
The logic of these functions should basically work like just their non-D versions, except they'd operate on the DIN status, not the INS status.
5. I believe the new function (ClearInsert) was probably based on a misunderstanding (admittedly, mine) and should be yanked. We don't need it.
6. SO ... how does all this fix things?
We would now have two status indicators that operate independently. When it comes time to apply them to an edit session, SPFLite would do THIS:
(a) When DIN mode is on, it TAKES PRIORITY. Regardless of the INS state, if DIN is on, the editor runs in DIN mode and implements DIN functionality, and the normal INS state would be ignored.
(b) When DIN mode is off, the regular INS state is inspected, and the editor runs in INS mode and implements INS functionality.
(c) When (a) and (b) do not apply, we are running in normal overwrite mode.
Because there would be TWO independent visual indicators, and two internal program variables that represent the states of these two indicators, and because they both are managed independently, neither can interfere with the other. So, neither can "break" the other.
We avoid "breaking" things by applying the "insert priority rules". By having two independent states, and a set of "priority rules" to coordinate them, we do not need a stack. And, viewed from the perspective of either INS or DIN , each can operate on their own, each without regard to the 'other' state.
Comments invited.