|
|
Post by George on Sept 22, 2021 15:47:15 GMT -5
This thread will contain the latest Beta release. By Beta, I mean one that is, in my opinion, at least good enough to let other users try it out. If you download and use one of these Betas, you should take precautions to be able to back off should it prove unstable. I will try to provide, with every version, any information that may affect switching to the Beta release. When a new Beta completely replaces previous versions, the download link for the previous beta versions will be removed. If you are running the latest production release, this Beta can simply be swapped in place of the production EXE. There is no current Beta, release 2.7.23056 is the latest production release.
|
|
|
|
Post by Stefan on Feb 2, 2023 8:46:59 GMT -5
George, I'm running v23029. I happened to run CFGMAINT -EXPORT and the log said it had dropped the [ODEFAULT] entries for CHARSET and SCHALIASALL for being Obsolete. The former is ancient, that latter is quite new, so either I have the wrong version CFGMAINT or we ought to be due a new CFGMAINT version.
I'm confused.
|
|
|
|
Post by George on Feb 2, 2023 9:11:47 GMT -5
Stefan: Hmm, yes, I'd better get the latest CFGMAINT posted. SCHALIASALL is new, itt's where the SCHEME alias names live. The other is correctly flagged as obsolete.
George
|
|
|
|
Post by Robert on Feb 16, 2023 15:33:45 GMT -5
Minor cosmetic issue with 23.047. If FIND QUOTED is issued when AUTO is not on, a message appears:
COMMENT / QuOTED operands not supported when Colorization is not active.
1. Typo where "QUOTED" has irregular casing.
2. I recommend this message be rewritten to avoid double-negative language and be more informative:
COMMENT/QUOTED operands require HILITE AUTO ON and profname.AUTO file defined
where 'profname' is the name of the currently defined profile; that part would have to be tailored for the specific file being edited.
|
|
|
|
Post by George on Feb 16, 2023 16:00:42 GMT -5
Thanks, I corrected the spelling and just said it requires full, active colorization to be on.
George
|
|
|
|
Post by Robert on Feb 17, 2023 13:25:58 GMT -5
Not a big issue, but the message doesn't mention INSIDE/OUTSIDE. Any way you can insert the specific operand used into the message so it's not a "generic" one? That way, they wouldn't get a warning for COMMENT when they used INSIDE.
I am not sure what you mean by "full, active colorization". I haven't seen your new message yet.
If colorization is on, it's on. Isn't it already "full" and "active"? Am I missing something?
|
|
|
|
Post by George on Feb 18, 2023 10:20:54 GMT -5
It takes HILITE AUTO ON AND a validly loaded AUTO file. i.e. If an error is detected in the AUTO file, even though HILITE AUTO is on, there is no valid colorization running.
I've adjusted the message.
George
|
|
|
|
Post by Stefan on Feb 18, 2023 12:01:21 GMT -5
George, I can live with the new keywords, but it disturbs me that these keywords depart from the usual SPFlite (and ISPF) syntax.
The "+/-" notation prefix was OK for the colouring eg +RED but we don't have +X/-X or +U/-U, we have X/NX and U/NU, etc.
Are there abbreviations for COMMENT QUOTED ?
And if the "+/-" notation is to be the way forward, why do we need INSIDE and OUTSIDE? Surely +COMMENT +QUOTED and -COMMENT -QUOTED will do the job without needing extra keywords, especially if there were abbreviations like +CM/-CM and +QU/-QU? (Note I treat the "+" or "-" as part of the keyword)
To my mind, the INSIDE/OUTSIDE implementation is less intuitve than -CM -QU which allows the user to specify what they want to achieve.
|
|
|
|
Post by George on Feb 18, 2023 13:12:02 GMT -5
Stefan: OK, I started out with C and NC; Q and NQ; but thought C by itself is also a Primary command (not that it would confuse the parser)
So I went with CM and NCM; QT and NQT.
Robert piped in pointing out they seemed cryptic, so, to avoid arguing, I went with COMMENT and QUOTED and their - versions. He also proposed the INSIDE and OUTSIDE variations.
Right now all 6 are mutually exclusive. My preference is to start over, and allow multiple operands.
Allowable combinations would be the same 6 choices we have now:
Q
NQ
C
NC
Q and C - Equivalent to INSIDE
NQ and NC - Equivalent to OUTSIDE
Complicates the parsing and testing a bit, but that's my problem.
George
|
|
|
|
Post by Robert on Feb 18, 2023 14:13:14 GMT -5
George, did you add these new operands on top of the longer ones?
I don't believe this was a good idea, for all the reasons I originally stated. No matter how they are written, these operands will be rarely used.
If you insist have having short operands, there should only be short ones, not both. (You didn't mention if the long are still here).
If you are determined to do this, allow me to suggest an analogy from blood types. There are actually only two fundamental blood type factors: A and B. If only only have one, it's A or B. If you have both, it's AB and if you have neither, it's O (the letter O, almost like a 0 Zero or a 'null').
Perhaps that could be applied here. If so, the arguments could be simplified to a single token. That would give you:
Q
NQ
C
NC
CQ - "inside" - you could have an alias of QC if you wanted
That leaves specifying the "open" or "neither" option. I don't like the idea of a plain O being an operand; it just seems wrong. Remembering again that this is an option that will be seldom used, that leaves
NCQ - "outside" - you could have an alias of NQC if you wanted
But, if you were willing to write operands as long as "NQ AND NC" or even "NQC" then how about simpler operands, which are both readable and short, and aren't currently used for anything else:
IN
OUT
Yes, it's true that these don't match the Q/NQ/C/NC and X/NX style, but either we can be rigidly consistent, or make something that is readable and easy to remember.
To me, IN/OUT has a lot to offer.
|
|
|
|
Post by George on Feb 18, 2023 14:43:31 GMT -5
Robert: Right now everything is 'long form', I haven't changed anything.
To me, the QC/CQ and NQC/NCQ variations are fine. I'm fine with these if we can all agree. I am NOT going to alter the Doc a 3rd time - do you all realize how many commands this addition affects?
George
|
|
|
|
Post by Robert on Feb 18, 2023 15:32:13 GMT -5
Do I realize? No, I don't; I am sure it's far more than you ever wanted.
I just wish that the "neither" case could be be made better. It's ugly when you define something by what it's NOT. Even OUT/OUTSIDE means it's NOT a comment and NOT a string. How do you describe what it actually IS?
I first thought, OPENCODE, then OUTSIDE, then OUT.
The only words that come to mind are OPEN and FREE (as in, "free" of being enclosed in comments or quotes).
The idea that is somehow trying to get conveyed is, 'Well, there's stuff that could have random, unconstrained junk in strings or comments, and "real" code that has to follow rules and makes sense.
Weird thought: Think about the FREE/OPEN as a third type of 'enclosure'. Then, each 'closure type' has two possible states: Either a search argument is found in it, or it's not. That allows for 8 possible states, if you think of the yes/no possibilities as as 0 or 1. Remember the Branch on Condition instruction? It had a 4 bit condition code mask, where (and forgive me if I label it wrong, but):
8 = equal
4 = high
2 = low
1 = other condition
That gives 16 possible ways to check something. Greater than or Equal amounts to conditions 8 + 4, etc.
What is unconditional branch? CC 15, and NOP is CC 0. You wouldn't need that in SPFLite, because CC 15 means look everywhere, and CC 0 doesn't make sense (find something but don't look anywhere? weird ...)
My point is, the BC condition codes are always searched for as an OR and never an AND. So, I am hoping you are not intending to actually use AND to connect the operands. If you had to, it would be OR.
Since you could ONLY use OR, that means you don't really need to say it.
Because of that, you don't need any kind of "NOT" specification. Instead, you'd only say where you ARE checking, not where you are NOT checking. That would give you:
Q - in a quoted string
C - in a comment
T - in open text
Want QC? It's just Q T
Want to find something that's in open text or in a comment, but not a string? IT's T C
No NOT'S. No dashes. No N prefixes. Nothing. Nada.
Just one, two or three separate letters.
I rest my case.
|
|
|
|
Post by Robert on Feb 18, 2023 15:39:32 GMT -5
Just a fine point. If all three letters Q C T are omitted, and you implemented this literally, it would suggest you are looking for the search argument no where; like a BC mask value of 0. So, as you process the operands, you'd start with a "mask" of 0, and "OR-in" the Q/C/T "mask bits" as you encounter them, but if they were never used, you'd have to plug in a "complete mask" that would be the same as if ALL the codes Q C and T were specified.
That's an implementation issue, not a design question. Just didn't want you to overlook it.
|
|
|
|
Post by Stefan on Feb 18, 2023 17:46:40 GMT -5
George, To me "Q/NQ" and "C/NC" make sense.
"Q and C" and "NQ and NC" rather less so as we don't have 'and' as a a connective word anywhere else (yet). So if we want the "in both" and "in neither" concept, why not use "QC" for the former and "NQC" for the latter?
|
|
|
|
Post by George on Feb 19, 2023 9:31:39 GMT -5
Stefan: Robert: The 'and' would not be coded, they'd be implied from the combination of the two operands. I was trying to indicate what the allowable combinatione were.
Robert: The C Q T approach would be fine, and it is simpler. I think this would be better.
If nobody pipes up, I'll proceed with this.
George
|
|
