|
Post by mueh on Jun 30, 2024 11:34:33 GMT -5
Hi George ! 24156 made change * Correct loss of a previous FIND/CHANGE search values by the SAVE command or intervening line search commands.
Since that msg "Line Reference: .zfind is invalid" . To reproduce f xxx;loc .zfind .zloc gives same error .
Thanks
|
|
|
Post by Robert on Jun 30, 2024 15:25:30 GMT -5
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
|
|
|
Post by George on Jul 1, 2024 9:56:35 GMT -5
Guys: .ZFind is not part of 'command chaining'.
This is caused by our giving so many commands access to the full search capabilities. Yet we want access to the 'saved' search values even though we may issue some of those 'other' commands that want access to do searches in between.
So there are two Parse objects, one for full search commands like FIND, RFIND, CHANGE etc. and the 2nd for the 'other' commands like PRINT, CUT, REPLACE etc.
Unfortunately I put LOCATE in the 'other' category, but because of things like .ZFIND it has to use the full search Parse object (that's where the ZFIND value is stored).
I've swapped it, and it's now working again.
George
|
|
|
Post by mueh on Jul 1, 2024 11:43:09 GMT -5
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
|
|
|
Post by Robert on Jul 1, 2024 12:14:38 GMT -5
It appears that there is a label problem both in V2 and V3.
If I say, CUT ALL "ABC"
and there are 3 lines that contain ABC, then LOC .ZFIND will go to the first line. FIND ALL does the same thing. But, the Line Labels doc says this about .ZFIND:
.ZFIND to indicate the last (most recent) line found by a FIND command
So, based on this definition, and assuming FIND-ALL-type commands operate from the first line to the last, .ZFIND should point to the last line found, not the first.
This seems to suggest that .ZFIND has been wrong for a long time.
R
|
|
|
Post by George on Jul 1, 2024 12:23:22 GMT -5
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]
|
|
|
Post by George on Jul 1, 2024 14:07:50 GMT -5
OK, I'll post a fixed version tomorrow (jul 2nd)
George
|
|
|
Post by George on Jul 2, 2024 10:10:50 GMT -5
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
|
|
|
Post by Robert on Jul 2, 2024 10:23:34 GMT -5
George, you know, the Help article "Line Labels" is the ONLY place that .ZFIND and .ZLOC are mentioned in the whole help.
Adding a couple new names wouldn't be a big impact, really.
R
|
|
|
Post by George on Jul 2, 2024 10:41:35 GMT -5
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]
|
|
|
Post by mueh on Jul 2, 2024 10:54:16 GMT -5
Hi George ! I can use without assigning label with line cmd f xxx first;loc .zfind;find xxx last;uu .zloc .zfind all so adding this additional special labels is in my oppinion no big improvement . Thanks
|
|
|
Post by Robert on Jul 2, 2024 11:29:04 GMT -5
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
|
|
|
Post by George on Jul 2, 2024 11:53:37 GMT -5
Well maybe it should be .ZFF for first and .ZFL for last - then it would be:
F ALL XXX; UU .ZFF .ZFL
|
|
|
Post by Robert on Jul 2, 2024 12:44:16 GMT -5
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
|
|
|
Post by George on Jul 2, 2024 13:56:56 GMT -5
Robert: If I do anything, it will be the simplest. And adding .Zxxxx variables is simpler than mucking about in SET-land. I don't care what the real .Z... labels are, choose whatever you prefer, they're just text strings.
I suppose this means we need 2 more for LOCATE as well, since LOCATE has an ALL keyword. Ick! This is evolving into another one of those creeping, ever increasing 'well, if we do this, then we should also do that ..., and then we can ..." scenarios. I hate it, I've been sucked into too many of these over the years.
A Doc. update is sooooo much simpler.
George
|
|