|
|
Post by Stefan on Apr 26, 2023 8:13:10 GMT -5
George, I'm not 100% sure, but I think this is an error, possibly/perhaps introduced by changes for preserving blanks within quotes, SETDIN, etc, etc made earlier this year. What do you think?
Consider some data like this...
=COLS> ----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+----9----+----
000002 arg$="AUTOBKUP " : val$ = Get_Profile$(Trim$(arg$)) : PRINTL(arg$+" "+Get_RC+" ["+val$+"]")
000003 arg$="AUTOCAPS " : val$ = Get_Profile$(Trim$(arg$)) : PRINTL(arg$+" "+Get_RC+" ["+val$+"]")
000004 arg$="AUTONUM " : val$ = Get_Profile$(Trim$(arg$)) : PRINTL(arg$+" "+Get_RC+" ["+val$+"]") Notice there is only ONE space between the double-quote (") in column 19 and the colon (:) in column 21. If I issue the following command sequence BOUNDS 6 20
CHANGE ALL ` "` `"` (that's CHANGE ALL space, space, double-quote TO double-quote) I expect only the double-quotes in column 19 of the above data to move two bytes to the left and everything from column 21 onwards to stay where it is. But that's not what happens. The whole line shifts left, as if the BOUNDS command had never been issued. However, if there are TWO spaces between the double-quote (") in column 19 and the colon (:) in column 21, the same command sequence works as expected.
Is this "working as designed" ?
PS: It so happens the example uses a double-quote, but the error occurs with any characters, whenever the edge of the boundary does not leave at least two spaces to the next non-blank char on the line.
|
|
|
|
Post by George on Apr 26, 2023 9:29:41 GMT -5
Stefan:
[UPDATE]
I see Robert deleted his intervening post that BNDS should come with a 'do not use' warning]
[/UPDATE]
I agree with Robert here. In simple terms, we should NEVER have supported BNDS just because ISPF did. ISPF had to work within the constraints of a 3270 terminal, we don't.
I would LOVE to yank it entirely, as it complicates so much code in so many commands. But I'm sure there'd be howls from some users saying it's essential.
Most times when a need like yours comes up, I TAG the lines and do a PT :tagname command. PowerType is so much simpler.
George
|
|
|
|
Post by George on Apr 26, 2023 9:54:29 GMT -5
Stefan: Examining code, the BNDS are applied to the search only, once found within the valid column range, the actual Change ignores columns. It just worries about the CS / DS differences and other complications like the various oddball literal type handling.
George
|
|
|
|
Post by Stefan on Apr 26, 2023 10:33:42 GMT -5
Horses for courses
I do not see PTYPE and BOUNDS as alternatives to each other.
I reckon BOUNDS is as useful now as it was in the 3270-era, despite the greater freedom we have now.
If you have and need to manipulate a consecutive bunch of pretty much identical lines, Powertype is great.
I find that constraint, plus the lack of support for primary and line commands, not to mention the (to my brain) counter-intuitive cursor positioning and key-mapping too much of a hurdle.
I grew up with BOUNDS (as did we all). I find it incredibly useful when I wish to edit 'stuff' whilst avoiding affecting the same or similar 'stuff' to the left of right of the target. The target lines can be anywhere in the file, they do not need to be consecutive, or even similar. I can use familiar Primary commands to manipulate the data. I can use BOUNDS with line commands too.
Bottom line: I KNOW that BOUNDS will do what I need and do it in the same way I PERCEIVE and THINK about the data I'm trying to manipulate.
I did see Robert's post - or at least a part of it - before it vanished. That's typical Robert.
He may have focused on the test data rather than the effect it serves to demonstrate.
In this specific instance PTYPE might have been helpful, but in thousands of other cases PTYPE simply isn't an option.
Just judging by the list of keyboard primitives, I guess PTYPE was Robert's idea. Good luck remembering which primitive is mapped to which key! Even something impressive like (PowerCopy) can be achieved without a 'model' line. What's more intuitive, let alone faster, than SHIFT-Mouse, CTRL-C, CTRL-V?
|
|
|
|
Post by Stefan on Apr 26, 2023 10:37:08 GMT -5
Stefan: Examining code, the BNDS are applied to the search only, once found within the valid column range, the actual Change ignores columns. It just worries about the CS / DS differences and other complications like the various oddball literal type handling. George OK - So there's no error then. It operaters according to the CS/DS rules. That explains why it works differently if there's a double/multiple-blank rather than a single-blank. Thx for looking into it.
|
|
|
|
Post by Robert on Apr 26, 2023 10:59:49 GMT -5
I am afraid that at present I am torn between my long-held desire to help users and make SPFLite better, and the reality that I'm not really welcome here any more. Hard to know which fork in the road to take.
The fundamental issue that has haunted BOUNDS since SPFLite started to implement it, is that IBM never fully explained what bounds MEANT. Does it apply to FIND only or also to CHANGE? I don't recall the ISPF manual ever really explaining it, other than showing a couple of screen shot examples, and saying, "see, this is how it works". In my mainframe days, I never saw any other developers using BOUNDS. And, I see the idea that the current BOUNDS applies to find but not change. That makes its behavior pathological.
And, it goes downhill from there. As more and more commands and features are added, they must either live within the poorly- (or NON-) defined BOUNDS semantics, or make a half-hearted effort to 'try' to be compliant to those poorly defined and more-poorly-understood semantics. The result is what we have now, a "no man's land" where you can use BOUNDS at your own risk, accept the result, fix the data in cases where it doesn't work out or cancel the edit and swear you'll never use it again.
I'd say, you ought to do a survey of users to see if anyone cares any more. If not, yank the BOUNDS feature. If you did, I would recommend just removing the user interface (the command entries, etc.) so it's not visible any more, then go about removing the actual code piecemeal as you get around to it, if that even matters.
I can imagine a better solution that would solve this problem, but it would require actual systems analysis and systems design. It would require real specifications that were understood and agreed to, and then implemented in a way that all commands would automatically follow it because the system design would give them no choice.
But, the last several times I have tried to promote ideas that I thought were worthwhile, you two - George and Stefan - turned my efforts into a living hell. It's totally demoralizing to try to help people and have them turn around and whine and nitpick everything, and doing so in a very disrespectful way.
I really, REALLY hate the current state of affairs. In my heart of hearts, I want to be in the middle of it all, because I love SPFLite. I always have. But I'll be damned if I am going to let you all attack me for trying to help you.
It's not really working for me. It's not only not working on general principles, but I mean, really, you DO know that I'm dying, right? How much do I have to beg and plead to get some sympathy and consideration from you people, anyway? Haven't I earned even the slightest smidgen of respect after putting my heart and soul into this thing for 15 years?
|
|
|
|
Post by George on Apr 26, 2023 11:52:10 GMT -5
Robert: You are, and always have been welcome. When I see one of your posts I think "Hey! Great! He's rejoined us"
WOW! Because we didn't like all your suggestions as offered? Because we suggested changes to your design? Certainly not.
Because you reacted to what we said as personal insults? You sure did! Neither of us EVER intended anything of the sort.
From my perspective your reaction came across as "How dare they question the proposals of the great SPFLite guru."
Sure, you had to re-write some stuff multiple times. Join the club I've been in all this time.
And your current:
Well, If you can be sensitive, so can I, you've been needling me for years on this. I take that as yet another criticism from you of my 'dive in and code it' attitude rather than your careful recommended analysis, design, specify, discuss, and only then code and test methodology.
Your 15 years of working with SPFLite should have well taught you that SPFLite is a can of worms internally (mostly due to my style). How do you expect to analyze, and design something that would 'automatically' follow those specs, when you have no idea of how the current internal logic flow is handled?
Your thoughts and ideas are very welcome, but trotting out the old analyze, design etc. methodology and demanding it as a prerequisite for future changes just doesn't fly over here.
We created and implemented many items over the years, quit trying to change my style, work with me the same way we have done in the past. We're both opinionated old men, we won't change, but we can still accomplish a lot.
George
|
|
