|
Post by George on Oct 24, 2022 14:05:07 GMT -5
The PUSH / POP options of the SET command were created way back in SPFLite pre-history, and neither Robert nor I can recall exactly what they were intended to accomplish.
So ... is anyone actually using them?
If so, how about telling us how? What support do they provide you?
It would be nice to eliminate the complex code currently in place to support them.
NOTE: We are NOT talking about removing SET support, just the PUSH / POP options of SET.
George
|
|
|
Post by Stefan on Oct 25, 2022 7:15:31 GMT -5
To avoid silence in response to your request - My answer is NO, I've never had a need to PUSH or POP a SET variable. ...and BTW... COMMAND CHAINING... occupies a large chapter in the documentation which I have read several times and still won't use - ever. While it is, what's the word, NIFTY, I think it is quite difficult to get right and certainly difficult to TEST.
From the description, it isn't something you can 'just do' intuitively and be sure you get the intended result. I suspect it was added early on, perhaps before Macros and some of today's commands were added. The example of
CHANGE ABC DEF .1 .100 ALL ; UC :ZF ALL ; LINE ')4' ALL :Z looks cryptic to me and I couldn't be sure that I've not messed up lines elsewhere in the file. In contrast CHANGE ABC DEF .1 .100 ALL MX ; UC ALL X DX ; LINE ')4' ALL X makes perfect sense without the :Z and :ZF bits.
Even easier to understand because you can see what's going on, but with one extra command
X ALL ; CHANGE ABC DEF .1 .100 ALL ; UC ALL NX ; LINE ')4' ALL NX
And I think a respectful "Sorry Robert" is probably in order.
|
|
|
Post by George on Oct 25, 2022 9:54:24 GMT -5
My two cents: I've never used command chaining, and probably never will. It takes too much brain effort to figure out how to take advantage of it.
Also, my usage of X and U lines is 99% a quick temporary usage, so they are always 'expendable' and I'm just more comfortable using commands with combinations of X / NX etc.
|
|
|
Post by Stefan on Oct 25, 2022 10:36:16 GMT -5
I mean no disrespect, Robert, it IS a NIFTY thing. But I see George occasionally looking to reduce complexity.
I appreciate it was probably your idea, but I wonder just how much use it gets compared to the amount of code it requires and the time it takes to (re-)learn the process.
I can't see opportunities for this mechanism popping up frequently enough for folks to recall the 'syntax'.
Even if the affected lines appear sporadically all over the file, we have tags and user lines and excluded lines and repeated RFIND/RCHANGE and MX and DX operands with which to locate and target lines.
And all of these are in more common use and thus feel more comfortable.
Hence I figure 99% of all users with the range of every-day commands at their fingertips, when faced with a requirement such as that outlined above, will.... EITHER simply enter the commands one at a time and press ENTER after each one, appreciating that they can verify the correct effect was achieved OR using the semicolon separator, enter a selection of commands they use every day and understand well, to get the job done.
CHAINING deploys a kind of "implied TAG command", but, depending on the preceding command :ZF can mean "found/affected" or "not found/affected" and :ZNF means the opposite.
Add in 'conditional' and 'unconditional' commands and :ZF tagged lines that were deleted, .... and it gets confusing. I assume, if I enter multiple, say CHANGE commands, the effect on the Z-lines is one of "AND" rather than "OR" logic, but I don't know. (I haven't tried it)
And after all that, I avoided the need to press <ENTER> a few more times and/or jump around with RFIND/RCHANGE.
I'm reckon I'm pretty geeky, but not geeky enough that the reward is worth the risk of making an incorrect change somewhere in the unseen bowels of my file.
Goerge, SNAP! We are uncannily alike.
|
|
|
Post by George on Oct 26, 2022 13:24:43 GMT -5
Just a FYI. I have no problems yanking code. Why? Because here, there and everywhere, I constantly see little 'wrinkles' in the code that were put in to support some obscure function or overcome some other "this isn't like ISPF" type niggle. Half the time it is far from obvious what they're for.
Many are because we 'bolted on' some new feature and it was more expedient to 'fiddle' several existing routines to get it to work.
So SPFLite code is a mess, despite several attempts by me to clean it up. That's why I complain about 'code clutter' and am always on the lookout for anything to remove. There's no way it will ever get fully re-written, so anything that can be done to remove unused stuff is a plus.
|
|
|
Post by George on Oct 27, 2022 9:40:42 GMT -5
Robert: Yanking code is simply way, way easier than adding/changing something.
|
|