|
Post by Robert on Feb 3, 2023 11:53:59 GMT -5
Not a bug. P'@' should find underscore? NO. Get_Curr_Word$ doesn't work? Wrong again.
Advice (not that you will listen):
1. You should test macro functions first before declaring they are broken. Like this (a macro that works):
' Get_Curr_Word.MACRO dim str_var as string str_var = Get_Curr_Word$ HALT("curr word", "'" + str_var + "'")
2. Read the manual. Read my words on the subject.
Working with SPFLite -> Finding and changing data -> Delimiters used to determine Word, Prefix and Suffix boundaries
If you are the one looking for a string, and you consider it to be a "word", how could SPFLite not treat it as a word and find it? For example, if you were looking for a word ABCD, and you said FIND ABCD WORD, it seems pretty straight-forward that if ABCD exists as a word, it would get found. However, what if you were looking for any four-character word? If the word only had English letters, you could be pretty certain you'd find it with FIND P'@@@@' WORD.
But suppose it were a four-character string that might have an underscore or dash in it; what then? Just saying FIND P'====' WORD won't work, because you would find any four characters, as long as there were delimiters next to it, and that's not what you wanted. The data you found could be well-delimited junk. How do you solve this problem, and only find what you really want - and nothing else?
First, you modify the WORD lines so that your set of valid WORD characters is correct. That "expands" the definition of a "word character" and removes those characters as delimiters. For example, if you add the underscore to the WORD characters, then it will no longer be considered as a character that delimits a word.
Then, how can you tell SPFLite to only look for the characters that you say are part of a special kind of "word" that you want? We could have changed how the @ picture works, but it's best not to tamper with that, so @ stays as-is, and only matches letters. Instead, SPFLite defines two extended picture code types:
& defines any character in in the set of WORD characters
% defines any character not in the set of WORD characters
So, if you want a four-character string of your kind of words, as defined by your settings of the WORD string, you would do this:
FIND P'&&&&' WORD
This works because WORD means a string delimited by non-WORD characters or the edges of a line, and the & picture means all characters which are in in the WORD character list.
What is nice about this is that the WORD characters are in the PROFILE, so whether you have ordinary text, C programs, COBOL programs, or some special-purpose data, you can customize each file type to exactly the definition of what a "word" means to best suits your needs.
|
|
|
Post by Robert on Jan 27, 2023 12:33:11 GMT -5
Well, if you don't need to analyze the issue and don't need to determine what your requirements are, you clearly don't need me. I give up.
|
|
|
Post by Robert on Jan 27, 2023 11:09:40 GMT -5
"I think the "DIN OVR" and "INS OVR" is too complicated. It suggests you can have two 'modes' active. Not possible, the keyboard can only behave one way at a time."
You are confusing these two things.
You DO have two modes active at the same time: INS and Data INS. And the keyboard DOES in fact only behave one way at a time: OVR, INS or Data INS. What SPFLite must do (which is a NEW behavior) is to PRIORITIZE these two indicators at run time, rather than allowing one to interfere with the other.
The problem has been that INS and Data INS currently DO interfere with each other. That needs to change.
I understand the reluctance to add a new indicator on the status bar. But it reflects reality: INS and Data INS are two different things which must act independently. Therefore, their INDICATORS need to act independently. They must.
|
|
|
Post by Robert on Jan 27, 2023 10:33:38 GMT -5
post deleted
|
|
|
Post by Robert on Jan 27, 2023 9:15:28 GMT -5
Andy, based on what I know (though not a DIFF expert), I don't think you can do what you had in mind.
If you are in the habit of needing this frequently, you could set up two 'work files' that you continually reuse, like C:\TEMP\WORK1.TXT and C:TEMP\WORK2.TXT and then compare those files.
To make this more convenient to type as a command, you could define SET symbols, like this:
SET WORK1 = "C:\TEMP\WORK1.TXT" SET WORK2 = "C:\TEMP\WORK2.TXT"
Then when you need to do your DIFF, you'd save each clip edit session like: CREATE =WORK1 CREATE =WORK2
Then you'd have these common work files available.
Not the most convenient way, but I can't think of how else this could be done, without DIFF being modified somehow. It would be a tricky change to make, because there is no way for one edit session to "reach over" to another edit tab and grab its data. SPFLite doesn't work that way. If you have existing, saved files, that's one thing. But to access one CLIP session from another CLIP session? Technically, I don't believe it's possible for SPFLite to work that way.
Maybe a DIFF expert out there can jump in and offer some help.
|
|
|
Post by Robert on Jan 27, 2023 8:48:59 GMT -5
After further thought, I believe a good abbreviation for the Data Insert indicator is DIN. It's short and sweet, and minimizes the amount of space taken up on the status bar by a second indicator.
|
|
|
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.
|
|
|
Post by Robert on Jan 26, 2023 19:41:14 GMT -5
Herein lies the problem: That is, the lack of a requirements list prior to implementing the Insert functions we have today.
What caused all this? In the beginning, there was only Insert. Then, one day, Insert "begat" Data Insert.
And what's Data Insert? IT'S A KIND OF INSERT.
So, if the basic (Insert) function will toggle off INS mode, it will ALSO toggle off d-INS mode, because d-INS mode IS A KIND OF INSERT MODE.
If that is NOT what is desired, then code would have to be changed so that d-INS mode is NOT a kind of (regular) INS mode.
That is, currently INS mode is plain-vanilla Insert, while d-INS is ALSO an Insert "with extra features" added in. Right now, the "extra features" do NOT mean d-INS another insertion state. It only adds additional features to the existing insertion state.
If we change it so that INS mode and d-INS mode are "never the twain shall meet", then both INS and d-INS would act independently, and you would ALWAYS have to pair INS with INS and d-INS with d-INS.
Is that possible? Yes. However, I contend that the semantics of doing that are too complicated to impose on the average user. It's too hard.
Right now, if you are continually mixing INS and d-INS modes, and you are in INS mode and then d-INS and you want to "revert" back to regular INS mode, you are going to have to press the INS key twice.
You want to only press INS once.
Again, this is not impossible to implement, but I believe the semantics of all this are too involved. I don't have to have to have a Ph.D. in "insert key science". It's asking too much of users.
Just saying. What you're asking for can be done, but I don't think it should be. What is present in the current beta works the way it should work. Does that conform to how your (involved) work habits play out? No, but for the majority of users, they are not doing that.
IMHO.
|
|
|
Post by Robert on Jan 26, 2023 16:13:19 GMT -5
I explored this suggested sequence of commands a few posts back. IMHO, doing what Stefan suggests is not a good idea, in the grand scheme of things. We must remember that whatever is implemented is going to be in place for EVERYONE, not just Stefan. I believe that making an overly-involved set of Insert functions is going to be too complicated, and most users will not understand them or will use them incorrectly. I believe my own reaction would be to delete all keyboard macros with any Insert functions, because I would no longer understand or trust them.
Is this an unsolvable problem? No. If there were really a case to be made for doing major surgery on all the *Insert functions, it should start with a properly thought-out design, one that takes into account the current implementation and avoids breaking the status quo without a (really) good reason.
(SPFLite) History tells us that no one wants to do design or systems analysis work; people just want the code hacked to get "their" fix done at this very moment. When code is written without a prior design, that's how bugs get created. Bugs do not "instantiate themselves" out of thin air. They are written - intentionally - even if the APPARENT intention was OTHER than creating a bug.
Here's how you know a 'feature' is actually a bug, or a bug waiting to happen: The more words it requires to explain something, the more likely it is, or will be, implemented wrong. I point out Stefan's encyclopedic explanation of Data Insert, and the suggested changes to it, as a bug waiting to happen. I gave up trying to read or understand it; none of his writeup makes any sense to me.
If y'all have a hankering to break all the Insert functions - and who knows, maybe that's the right thing to do - BUT if you don't sit down and rationally figure out HOW the h*** this is all suppose to work properly - AND in a way that makes sense to non-geniuses - then you are asking for trouble. That is, MORE trouble than you seemingly have now.
This is an "I told you so" moment. Take in this moment, and respond to it accordingly.
|
|
|
Post by Robert on Jan 26, 2023 15:55:42 GMT -5
Yes, the keyboard where / is hard is German, that's why Stefan asked for the / \ options to be typed as . and .. instead. Maybe you forget.
In any case, you already have short name: W
Right now, if you type W on a line having MYFILE.TXT the W command uses the windows Shell to open the file. The Shell figures out that .TXT file are opened with NOTEPAD by default, so that's what it does.
If you want a 'normal' FM command format, then I suggest allowing W to accept a command parameter, and then use it to operate like your EXEC/EX does. An advantage for that is that it doesn't introduce (or, use up) any new letters or names; it just enhances the W command you already have.
You can probably merge the existing W and EXEC line-command source code to make a single, more powerful command.
If you don't like the leading / for EXEC (but it's so nice ...) then an enhanced W would be my vote.
|
|
|
Post by Robert on Jan 26, 2023 14:45:59 GMT -5
FYI(2).
Eventually, the Help will need to get fixed. The "Shifting Data" entry, and the one for (DataInsert) currently use reverse video in the doc for purposes that are inconsistent with what you have currently implemented in the beta. (as noted above) it's good for all INS players to be consistent, including the doc.
|
|
|
Post by Robert on Jan 26, 2023 13:55:18 GMT -5
FYI: Your new INS fix does not currently operate in FM.
Oddly enough, d-INS appears as "ins" in FM.
Would be nice if all the 'INS players' did it consistently (though, I don't recall ever using INS in FM).
|
|
|
Post by Robert on Jan 26, 2023 13:33:20 GMT -5
Yes, use / as the "name". "/" can never be part of any program name, and is not currently being used for any purpose. Even in Edit, "/" is an option on a line command, but not a command itself. So, "/" does not clash with any existing usage.
If you did this, you would not have to "hack" the FM line command processor. And, it would be easy to type and would not require a space after it to work.
So, Notepad would run by putting /NOTEPAD on the line command. Easy-peasy.
Then, I can get rid of my =.MACRO
===> P.S.
For uses with non-QWERTY keyboards that have a difficult-to-type / key, you could let a , comma work as an alternative / command.
A lone-dot now acts like S in FM, and ".name" is a request to use overriding profile "name", so you can't use dot.
But, a comma is now treated as an illegal command, and so is available.
So, for non-QWERTY users, they would issue:
,NOTEPAD
to get the same thing done as /NOTEPAD
|
|
|
Post by Robert on Jan 26, 2023 12:45:34 GMT -5
It turns out that, in all likelihood, the only command I would ever run like this is Notepad++
Since I know that, I made a clone of =.MACRO called NP.MACRO that only runs this program. So now, I don't need an = sign at all to run this, just NP
So, there is no need to do the 'hack' described above; not for me, anyway.
|
|
|
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.
|
|