|
|
Post by George on Apr 30, 2021 9:49:52 GMT -5
Robert: There's more than one way to skin a cat. This kind of thing shouldn't be hard to add. While I'm checking out the primary commands in 2.5 I'll see what it would take. It's not the parsing, but the command code, and all those are pretty small code blocks.
George
|
|
|
|
Post by Stefan on May 1, 2021 1:46:16 GMT -5
Robert,
I might be misunderstanding what you are requesting. The subject line says PRIMARY commands but the example are all LINE commands, and the request speaks of column ranges but mentions <line control range>
Re column limits:
Why couldn't the these commands (or others for that matter) not simply honour the BOUNDS setting? ISPF users are familiar with the concept of BOUNDS, so this would be the most natural and intuitive way of implementing a limited column range for any line commands. And the BOUNDS command already works exactly as you describe.
Re <line control range> Use the LINE primary command.
It already offers a <line control range> operands and is specifically designed to apply line commands from a primary command context. I'm sure it could have column range added to its operands
|
|
|
|
Post by George on May 1, 2021 9:31:41 GMT -5
I hadn't even looked at the code until Stefan's comment, but I checked and yes, UC etc. commands DO honor Bounds. Adding column operands simply would allow a temporary override of BNDS without having to set BNDS, do the UC and then reset the BNDS.
No, LINE can not have column operands as the line command issued is actually done by the Line Command code, none of which support bounds or column boundaries. And no, they never will.
George
|
|
