|
Post by George on Jan 13, 2023 14:54:08 GMT -5
Robert: Reviewing and evaluating whether some enhancement needs to be built-in or maybe can be handled via a macro is not always clear cut or obvious.
So - Please - Doomsday? Stating an obvious impediment?
If re-writing the colorization support to do it via a proper parse is not a total re-write, then I'll pass the current source to you, freeze any changes I might want to make, and let you 'have at it' till you pass it back complete and working. If it's not a total re-write, it shouldn't take you long.
But I know this idea won't fly. Years ago you were going to handle the addition of some new command you'd proposed, a reasonably straightforward one, and you wanted experience in handling a complete addition like that to gain some experience in SPFLite internals. We know that one went nowhere.
I may come across as negative, and shoot things down often. Maybe I don't read things with an 'open mind'. But I'm on my own, with suggestions for tweaks and enhancements coming from multiple parties, let alone locating and correcting the reported bugs.
I spend far too many hours a day on this thing, ask Linda. Just juggling all this traffic on the forum is exhausting without being treated like I'm some roadblock to progress.
George
|
|
|
Post by Stefan on Jan 14, 2023 5:05:43 GMT -5
You don't need qualified macro names for this. I dare say that would be overkill just to invoke different versions of the same macro.
You could either code language-specific processes in subroutines inside a the main macro
or
Use the main macro to determine the filetype/assigned Profile and build an apprpriate SPF_Post_Do to call the macro nsme you want.
No need to changw the Parser and introduce a new command notation.
|
|
|
Post by George on Feb 14, 2023 14:53:21 GMT -5
Stefan: Try out the new CM NCM / QT and NQT operands in the latest Beta.
George
|
|
|
Post by Robert on Feb 14, 2023 20:50:55 GMT -5
This is an interesting development, but I feel that the spelling of the operands is too cryptic, and may be hard to type correctly. You did so yourself in the Beta announcement, referring to NQT as NCM. That was a cut and paste error, but if even you as the author did not see that, how will users fare?
I recommend these names, which should be easier to remember:
COM - Locate the search argument if within a source Comment NCOM - Locate the search argument if NOT within a source Comment
STR - Locate the search argument if within a String NSTR - Locate the search argument if NOT within a String
Possible enhancement:
COMSTR - Locate the search argument if within EITHER a source Comment or a String NCOMSTR - Locate the search argument if within NEITHER a source Comment nor a String
Of course, these keyboards now become reserved and should be highlighted on the primary command line.
|
|
|
Post by George on Feb 15, 2023 13:15:49 GMT -5
Robert: OK, maybe alternate names would be better. But I do not like STR. Strings as just one of many data types in a computer language, there is no standard that strings are quoted.
How about LIT and NLIT? I guess that would make the other COMLIT and NCOMLIT
I started with much shorter ones, in the theme of X / NX and U / NU.
So how about C and NC and Q and NQ ? I guess that wou make CQ and NCQ. Hmm, getting cryptic again.
George
|
|
|
Post by Robert on Feb 15, 2023 17:29:30 GMT -5
This is an area where there is no obvious answer. We are beyond ISPF, so asking "how would IBM do it" doesn't work here. We now have to ask, "how would SPFLite do it". X/NX has the benefit of ISPF history. What is the "SPFLite history" here?
Consider that part of this (sometimes animated) discussion touched upon the concept of colors. First a few words about your ideas.
1. I am not sure the objection about STR is a good one. There is no standard that strings are quoted? Perhaps you could give an example. The only one I can think of is FORTRAN IV and its H-literals. They were truly awful. Aside from some very weird language maybe like LISP, I think there pretty much IS a standard, and it's either "xx" or 'xx' unless you know something I don't. Main area where there is NO standard is how to handle embedded quotes as data values.
2. "LIT" could be a problem, because 123 is a literal too. Only real definition of a literal is a self-defining term that does not dependent on or refer to anything else. It doesn't even have to have quotes or digits; in COBOL, ZERO is a literal.
A "comment" could also be called a "remark" or "note". But, "comment" is pretty much the name most people would see. No real argument here.
Now, back to colors. Reason I bring this up is we already have a notation like this:
RED = find strings that are red +RED = change color of found strings into red -RED = find strings that are NOT red
Part of the "cryptic" issue is that the leading "N" throws things off. Using – instead of N might help.
However, this gets into a common hangup among developers, where they want to optimize everything. I have a saying, "Don't optimize something you never (or, hardly ever) do".
Right now, we've NEVER had the choice to discriminate on the search context in this way. Why does any of it have to be so short, anyhow?
In language theory, there is an idea that the more often a word is used, the shorter it should be, and vice verse. The fact that the indefinite article in English is "a" and not some long word is no accident. In contrast, there is no real demand to make "transmission" short, because we hardly ever say it.
C? Q? Yep, very short, but for an attribute that will be rarely used, shortness doesn't matter. Why make them short at all? I thought for a moment that we could even use ## for comment and $$ for strings, but that's just as cryptic.
Why not say STRING and COMMENT? You know, something obvious? How would this work?
First, somehow we have to deal with the case where you want to handle combined tests, like comment-or-string. And, even operands like my COMSTR are not so hot.
What would we MEAN if we asked to find a search value that was NEITHER a string NOR a comment? What would YOU call it?
I know what I would call it: "open code".
Put all that together, and what do you have?
STRING value must be inside a quoted string
-STRING value must NOT be inside a quoted string
COMMENT value must be part of a comment
-COMMENT value must NOT be part of a comment
OPENCODE value must be in "open code" that is, it must NOT be part of a string or comment
-OPENCODE value must NOT BE in "open code" that is, it must EITHER be part of a string, OR be part of a comment
|
|
|
Post by Robert on Feb 16, 2023 8:25:42 GMT -5
The proposal above is a good start, but it still has an issue: OPENCODE. That's not really a word, and what does –OPENCODE mean, again? Conceptually, it's a problem. It's not as obvious as STRING and COMMENT.
There is a way around this, but it would require deviating from the pattern a little. Instead of using a – sign for this part, suppose we used to different words. That could give us:
OUTSIDE value must outside of any string or comment INSIDE value must be inside of either a string or a comment
I think these two operand names make more sense than OPENCODE and –OPENCODE and will be easier to remember.
I wish there were an easier way to figure this out all at once, without constantly saying, "wait, there's a better idea".
But, I believe, at the beginning of any new feature, it's very important to get the names right, and creating stuff is hard.
Whatever is decided tends to stick for a long time, and it needs to be done correctly.
|
|
|
Post by George on Feb 16, 2023 10:58:15 GMT -5
Lets just forget STRING, we disagree on it's definition. Since the length of the keyword doesn't seem to matter, how about QUOTED. That way COMMENT and QUOTED match the keywords in the AUTO file. INSIDE and OUTSIDE are fine.
So we'll have COMMENT -COMMENT QUOTED -QUOTED INSIDE OUTSIDE
George
|
|
|
Post by Robert on Feb 16, 2023 14:27:48 GMT -5
I still like STRING, but matching keywords in the AUTO file is a good principle to follow, better than using a "nice" word like STRING that doesn't match up to anything.
Yes.
|
|