|
|
Post by Stefan on Apr 18, 2021 2:08:30 GMT -5
This probably applies to all primary commands that accept an optional 'search-string' operand.
On the EXCLUDE primary command, the 'search string' operand is optional.
I enter a FIND 'search-string' command.
Subsequently, I can enter RFIND to move through the file to other occurrences of the same 'search-string'
Similarly I can enter EXCLUDE 'search-string' and subsequently use RFIND to 'pop out' excluded lines containing the same 'search-string'.
However, if I enter FIND 'search-string' followed by EXCLUDE .30 .40 (ie. WITHOUT a 'search-string' operand), the RFIND command is defeated (Msg: No prior search values to use')
So I cannot FIND <something>, EXCLUDE some lines by line numbers and then expect RFIND to locate the next <something>. From a user perspective, this is wrong because the user hasn't done anything to change or remove the active 'search-string'.
Perhaps this is less a bug than a suggestion, but... All commands which accept an optional 'search-string' operand, should NOT reset the 'search-string' value, unless the 'search-string' operand was actually supplied.
|
|
|
|
Post by George on Apr 18, 2021 10:10:27 GMT -5
Stefan: Nice thought, but no.
A command that specifies, say, a line range without a search string should do exactly what's asked of it. Just because there's a previous search string laying around does not mean it should be incorporating that string search. How on earth is the parse routine supposed to know which previous search operands to reset and which to retain? The absence of a search string (where one is allowed) IS a new search string.
And anyway, I am not going to fiddle with the universal search routine or the parsing it takes to handle it. The routine is just too heavily used by commands and other internal routines. I just don't need the headaches.
George
|
|
|
|
Post by Stefan on Apr 18, 2021 10:42:34 GMT -5
George, Ahh, sorry. You misunderstood what I am asking for. I'll try and clarify...
But first - if this is all part and parcel of the universal search routine - then maybe you should forget it.
By All commands which accept an optional 'search-string' operand, should NOT reset the 'search-string' value, unless the 'search-string' operand was actually supplied.
I meant that the the command (EXCLUDE) in my example should absolutely fo what the user requested.
But at the moment, if I
1) FIND <something> 2) EXCLUDE .10 .30 3) RFIND <=== no longer finds <something>
The RFIND says there's no string value to find.
The reason is that the EXCLUDE command, although no <search-string> operand was specified, effectively reset/cleared the <search-string> which was set by the FIND command.
I'm absolutely fine with the concept that there is only ONE <search-string> value at one time, and it applies to all commands with a <search-string> operand. So any of those commands can and do set the <Search-string> value when they are called. All I'm asking is that when such a command is called and the user does NOT enter a 'new' <search string>, that the command does not 'clear; the <search string> that is already in effect from previous commands.
That way, if the user asks any of the commands which take a <search string> to look for something, s/he can subsequently enter any other commands in the certain knowledge that RFIND will still locate the next occurence of whatever they last searched for. That should apply even if they subsequently use a command which could have had a <search-string> operand but the user did not specify it.
In my case. I intended EXCLUDE .10 .30 to do just that. No mention of a <search string>, so I did not expect or desire the <search-string> from a previous FIND command to be lost/reset to null. Had I used EXLCUDE .10 .30 'ABCD', I would absolutely expect that the <search-string> used by RFIND from here on in would be 'ABCD' and not whatever the FIND command had put there.
Hope that helps.
|
|
|
|
Post by George on Apr 18, 2021 11:16:06 GMT -5
Stefan: I was clear.
As I said before, when parse starts to scan operands for EXCLUDE, it has a parse structure to fill out with the result of all the operand scanning. All kinds of other routines are dependent on this parse output structure.
How can it do anything BUT reset this structure on starting the scan? I'm totally lost as to how you expect some of the previous parse's output to be retained and others reset? Who chooses? What about color selection? U/NU? WORD? PREFIX etc. etc. Which of those gets RESET and which don't? It's impossible.
George
|
|
|
|
Post by George on Apr 18, 2021 15:06:17 GMT -5
Robert: I'm reluctant to do even this. The * construct is, to me, a crutch. When you have RETRIEVE to bring back long complex command strings, it's a no-brainer to create/re-create whatever command you really want.
I think sometimes we get into this "lets jump through hoops so that I don't have to enter a couple more keystrokes".
ISPF and SPFLIte are keyboard oriented editors, always have been. Why are we so focussed on saving a keystroke here or there? Yes, efficiency is nice, but at what cost?
George
|
|
|
|
Post by George on Apr 19, 2021 11:57:44 GMT -5
Robert: The problem is what would * mean? For good old ISPF it was simple --- the Find string and the Change string, maybe WORD PREFIX etc. And only FIND CHANGE and EXCLUDE even supported search parameters. But Stefan wanted to do a FIND with parameters, then an EXCLUDE with parameters, and then have RFIND use the original FIND parameters.  What is the parse for EXCLUDE supposed to do, it's scanning and building the same universal search routine parameter block that has the old FIND parameters sitting in it. I think sometimes we're forgetting how pervasive that routine is, the thought of fiddling with that code, which took a long time to get working properly is scary. It has so many little wrinkles and exceptions in it to accommodate all the variations in how it is called. It's used by 30+ commands, do you want to test them all to make sure a new bug hasn't been introduced? Go ahead, ALIGN, APPEND, CHANGE, COMPRESS, CREATE, CUT, DELETE, EXCLUDE, FIND, FLIP, JOIN, LC, LINE, NDELETE, NEXCLUDE, NFIND, NFLIP, NREVERT, NSHOW, NULINE, PREPEND, PRINT, PTYPE, RCHANGE, REPLACE, REVERT, RFIND, SC, SORT, SHOW, SPLIT, SUBMIT, TAG, TC, UC, ULINE are all waiting to be tested. Come up with some specific ideas as to how it would work after considering all the above use cases and maybe I'll have a look, just don't say 'be consistent'. George |
|
|
|
Post by George on Apr 19, 2021 14:11:33 GMT -5
Robert:
CHANGE ABC DEF WORD 20 30
EXCLUDE .10 .20
RFIND
Does the RFIND honor the ABC WORD and the column restrictions and the .10 .20 line restrictions? Or would the global F/C strings be acted on alone (like a FIND ABC), or is it like (FIND ABC WORD) or like (FIND ABC WORD 20 30) or maybe they get merged with the operands from EXCLUDE to create a (FIND ABC WORD 20 30 .10 .20)
Throw in all the other optional FIND operands and lets start picking and choosing which get saved in 'Global' areas, which get ignored, which get merged etc. This could get confusing and we're trying to simplify, I thought.
See where I'm going?
George
|
|
|
|
Post by Stefan on Apr 19, 2021 16:04:00 GMT -5
Robert,
Excellent explanation. It didn't occur to me to go back to the ISPF manual, because it had recently be mentioned that maybe SPFLite should decouple a bit from ISPF. (Especially the documentation is heavily ISPF-focused, probably unnecessarily so as ex-ISPF-jockeys can find their way around just fine whilst folks with PC-only experience will struggle much more)
The situation is relatively simple to my mind. Historically, FIND and CHANGE are related and share the data from each other's input/operands , i.e search-string, column and limits, et al. Whatever the user supplied. RFIND is an extension of that pairing and the clue is in the name RFIND as in REPEAT-FIND. So, FIND, CHANGE and RFIND operate as a team.
Today, SPFLite goes further, offering various other commands that accept 'search' criteria and column/line limits, etc. And these commands have become part of the 'search-criteria' sharing team.
RFIND doesn't operate purely as "Repeat last search as-was".
It operates as "Repeat what the last search command DID"
For example: If I type EXCLUDE STEF, the first line containing STEF is excluded. PF5/RFIND does not find the next line containing STEF, it excludes the next line containing STEF.
(Some might even argue that RFIND should just repeat the 'search' aspect and not the 'commands-action' aspect.)
George, you asked for specifics.... so I ask you to consider this: The above all makes perfect sense as long as all commands that 'share' the 'search criteria' of a previous command, REQUIRE the user to always supply a <search-string> operand.
That is not always the case. For example, the EXCLUDE command can, optionally, operate with a search string, but also operates very usefully without one.
Now, as you rightly pointed out, the search-string isn't the only operand involved. What about column limits, line limits, X/NX U/NU, etc, etc? The change I'm suggesting is...
If a user does not provide a <search-string> operand to a command, then that command does not clear the 'search criteria' data block for use by subsequent commands.
Yes, that implies two copies of the "criteria block" - see next paragraph
That means if the <search-string> operand is absent, do not clear any existing search-criteria from the copy of the block.
I gather from your previous posts that there is only ONE location where the command Parser stores the 'search criteria' block derived from the command's operands and that this is reused for every subsequent command. I figured you'd maintain a transient 'search-criteria' block for the current command, to feed to the universal search routine, etc, etc. But I also assumed (wrongly!) that you would store a more 'persistent' copy of that block elsewhere for use by subsequent command like RFIND. The copy would 'persist' only until the next command that actually specifies a <search-string> comes along. Then it is updated with all relevant data from that new command. This approach also allows extended implementation of the '*' syntax from ISPF. The syntax like FIND * <other optional operands> would simply 'prime' the 'transient' criteria block with only the search string from the 'persistent' copy, before the Parser augments the block with data from any other operands.
And the syntax FIND ** <other optional operands>, would prime the 'transient' criteria block with ALL data from the 'persistent' copy, before the Parser overlays it with data from the other command operands. (Although this last option is really just a short way of stepping through RETRIEVE to recall the previous command and overtyping the operands yourself)
Anyway, that isn't the way of things, so I understand if you decide that the required changes are not worth the benefits.
|
|
|
|
Post by George on Apr 20, 2021 11:51:27 GMT -5
Robert: Stefan:
Yes, nitty gritty details of what RFIND does are not documented. And frankly if I was forced to do it, it would take a lot of code reading to dredge up those details. And yet more pages of Doc. to confuse people.
There is one primary data block for the search criteria (there are a lot of operands), I'm just about at the limit for flag bits to track them all in a DWORD - 64 bits). We're not talking just a handful of values here.
And yes, there is a secondary area for saving RFIND stuff.
I'll agree that things need improving, but it's fair chunk of work. There I go complaining again.
You guys get to sit back and toss out ideas and as long as they're logical and justified, you're done.
I get to figure out how to somehow fit it into the maze of code that's been woven over the years.
I think I know what you want/need, let me mull it over.
George
|
|
|
|
Post by George on Apr 21, 2021 9:37:57 GMT -5
OK, I'll tackle these RFIND revisions, but this won't come out soon. To do it right means some significant internal revisions, so take a breath and hold it for version 2.5. I won't attempt it on 2.4, it's not truly settled down itself yet.
George
|
|
|
|
Post by George on Apr 21, 2021 12:00:22 GMT -5
Robert: I'm not sure what 'secrets' you think are lurking in the bowels of RFIND. What it does is quite simple.
1. When FIND/CHANGE are finished, their find/change strings are saved.
2. When RFIND/RCHANGE come in, they look to see if the previous strings are null or not, if not, they proceed.
3. If they are null, you get the "No previous Find/Change message"
4. Our problem is that so many other commands end up breaking what's saved by 1. above, and triggering the dreaded 3. response.
That's it, there simply are no secrets to spill.
George
|
|
|
|
Post by George on Apr 21, 2021 14:42:43 GMT -5
Robert: If you want the nitty gritty of what's happening inside, yes it would take lots of words to describe all the nuances of how it "does it's thing". I can't believe users would want or need to know that kind of thing.
As I pointed out, my reaction when someone says 'all you have to do is blah and blah, that would solve it', is to shake my head and think 'if you only knew ...'. And I trot out the old 'it's more complicated than you think', which always then triggers your normal push-back.
You seem to have been implying that if you only knew more about RFIND and it's internals that it would somehow empower you to be more efficient or something. Those 4 points above are it. Everything else is programming logic and should be of no concern to users.
George
|
|
What is the parse for EXCLUDE supposed to do, it's scanning and building the same universal search routine parameter block that has the old FIND parameters sitting in it.