Line Reference: .zfind is invalid since 24156

Hi Mueh,

I am afraid you've been missing staff meetings. The .zfind notation was part of the "command chaining" feature. When George did his parser rewrite, he chose to remove command chaining, since it evidently does not fit into his new parsing architecture. I wish he hadn't done that, but if you want this kind of stuff to work, you will have to take it up with him. There is no way that I know of that you could simulate this like with macros.

R

Hi George !
Installed 24183 ( Title shows 24178 ) .
Problem is solved for LOCATE but i use .ZFIND very often in cmd's like SHOW EXCLUDE CUT and maybe other's .
Ir is unacceptable for me that .ZFIND .ZLOC can't be used in line range for any cmd where it can be used before .
Problem occures since 24156 ( okay in 24152 ) .
Thanks

Robert: No, in the prod version (24069), .ZFind points to the first found in an ALL situation, we have a bug.

George

[UPDATE]
Sorry - mispoke.

Our problem is STILL the fact that we want full search abilities for the majority of our commands, yet we still omehow expect to be able to do that and STILL retain the search criteria, the .ZFIND etc, even though those values are logically supposed to be reset by any new search.

So I created two search data control blocks, and assigned each command to one or the other. The groupings being FIND/CHANGE/LOCATE and associated Rxxxx commands, and everything else.

But now it seems we want to have our cake and eat it too.

We want the 'other' commands to still have access to the main FIND/CHANGE/LOCATE search control area.
And if we do so, we mess up RFIND etc.

I can fix this problem (.ZFIND etc) by floating those variables up to the Tab data level, and remove them from the Search control data. That's the only fix I can come up with that should work.

George

[/UPDATE]

MUEH: Robert:

MUEH: read Robert's post under Suggestions.

OK, I've corrected MUEH's problem of not being able to use .ZFIND in many of the 'other' commands.

But Robert brings up the fact that .ZFIND has NOT been doing what the Help describes for a very long time. It seems to have started around SPFLite2 - V3.0. (March 2023), maybe before that. There is specific code in place to force .ZFIND back to the 1st occurrence.

I really don't want to add yet more .Zxxxxx names. We know that it has been wrong for well over a year now, without a complaint. (MUEH's problem is not about .ZFIND being first or last).

My vote is we 'correct' the documentation to match what's actually happening. I seriously doubt anybody will even notice, let alone care about it.

George

Robert: Yes, I know, I searched for it too. The doc isn't the problem. Remember, I'm trying to stop 'fiddling with' the code and put this to bed. Lately when I fiddle, even simple things, I mess it up.

George

[UPDATE]

I looked, it requires saving the last location in global tab data as well, like I said, nothing difficult, but fiddly.

And after a year+ of no complaints with the as-is, just who are we doing this for? Nobody will care or ever use it.

[/UPDATE]

George, this would be more fiddling, but just suppose you could do this:

FIND ABC FIRST
SET .A = .ZFIND
FIND ABC LAST
SET .B = .ZFIND
UU .A .B ALL

Yes, this would require a new SET syntax, but you'd see by the initial . that it was this new kind of SET.

Just sayin'

R

Yes, that is a possibility, but it causes more problems.

1. .ZFF and .ZFL look an awful lot like .ZF and .ZL and will cause confusion.

2. .ZFF and .ZFL add two new Z names, the thing you said you didn't want to do.

3. If you add .ZFF and .ZFL for FIND, what about LOCATE? .ZLF and .ZLL? Or, just don't support LOCATE?

You didn't like .ZFINDA and .ZFINDB because they were new Z names and it involved more code fiddling. This doesn't seem to help.

Maybe you don't like SET .A = .ZFIND, but it doesn't add new Z names and is easy to understand, but at the cost of modifying SET or making a new command like SETLABEL or LABEL instead of overloading SET.

R