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.
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.