|
Post by Robert on Feb 19, 2023 10:39:15 GMT -5
I was hoping you would say that. This was another in a list of (not overly) contentious debates on a new feature, but I believe by everyone stating their case with good rationale, everyone influenced everyone else. I never would have dreamed of suggesting C Q T at the beginning, but now that it's out there, it seems to make sense.
I wanted to mention, when a user issues a command with these codes, they would never need to specify all 3 of them, because that is the same as searching everywhere. But, a macro user might define these codes independently, and it might be tricky macro code to avoid the case of specifically asking for all of C Q and T. So, even though as a user-written command nobody would do that, I believe you should allow for it in the syntax.
|
|
|
Post by George on Feb 19, 2023 12:08:39 GMT -5
If all 3 are specified the command is killed with "All 3 operands (C Q and T) together is illogical".
Either typed in or in a macro call, same error.
I'll be posing a revised Beta shortly with all this. In testing it seems to work just fine.
George
|
|
|
Post by Robert on Feb 19, 2023 12:47:57 GMT -5
In testing 23.050, the new operands don't seem to work with NEXCLUDE.
I tried to find a string that happened to appear in both T and C modes (in a macro) and I couldn't get any any combination of C, T or Q to find them.
One thing to consider for N-type commands like NX is it puts into question the meaning of the C/Q/T options.
Issue (easy case):
FIND ABC C Q -- find ABC if present in Comment or Quoted
Hard case:
NX ABC C Q -- exclude lines not having ABC -- but what about C Q ?
Here's the deal: If a line does NOT have ABC, then it is NEITHER in C, Q or T -- because it's nowhere.
Therefore, the C and Q have to somehow apply to lines where ABC does appear. I *think* the correct test is,
"if ABC is present in either Comments or Quoted, then OK; otherwise, exclude it". That means, in this example, if ABC is present in Text, it has to be treated AS IF it was not present, for purposes of exclusion by NX.
This is kind of tricky logic, and needs to be thought through to make sure it's being done correctly.
Unless this kind of adjustment can be made, C/Q/T would have to be disallowed for N-type commands.
P.S. I don't think allowing all of C/Q/T is actually illogical, it's just redundant. I believe a better way to handle it is to not issue the error, and if they happen to specify all three, just ignore it. It doesn't hurt anything.
|
|
|
Post by George on Feb 19, 2023 14:08:14 GMT -5
Robert:
a) None of the Nxxxxx commands are done. Why? Because the double negatives in thinking about it drove me nuts. The Nxxx commands are all like that, working on them at any time is brain busting. My inclination is that for most users, trying to wrap their minds about coding a command would also be too much. My preference is to NOT support them on the Nxxx commands. The reason they're accepted right now is a peculiarity of how the parser now works.
b) C/Q/T is illogical, I don't see it as a big deal to remind them of it. Accepting operands, doing nothing, and not saying anything is not a great idea.
More importantly, did the C Q T work properly on the rest of the commands?
George
|
|
|
Post by Robert on Feb 19, 2023 15:01:30 GMT -5
Whether you end up supporting C/Q/T on N-type commands is up to you. If you choose to tackle it (and I hope you do), I believe the way to resolve it by NOT thinking of this in terms of "double negatives". Nobody likes them - neither you nor the users. I know I don't.
Go back to the definition of NX: It means, "use the NEXCLUDE command to look for a search string, and exclude (conceal) the lines that do not contain the string from the display".
What is needed for C/Q/T support is NOT by implementing "double negative logic" but by enhancing what "look for a search string" means.
Allow me to create a generic term to describe the separate areas of a file that are described by C/Q/T: call these areas "regions". So, data that is found by FIND ABC T is, by definition, in the "T region". To describe in general terms what you are looking for when a FIND command has C/Q/T codes on it, the data that actually gets found is found in the "target region" - which simply means the part of the file where you are looking that is eligible to be searched is the "target" of your search processing, based on the C/Q/T code(s) currently in use. (A "target region" might involve more than one code. If you say FIND ABC C Q, the area being searched is the C region + the Q region. Maybe that's like "one composite region". I don't want to get overly wordy about all this.)
OK so far?
So, for an NX ABC ALL T, then on any given line, if ABC is found in the target region, OK; otherwise the line gets excluded.
For NX to find the string in the target region, there has to BE a target region on that line. A line that was entirely only a string or comment wouldn't HAVE any T region, and so you couldn't find your ABC there, under those conditions.
It *might* be possible to use this fact as an optimization strategy. IF you knew that a line was entirely a comment (only having region C data) a search looking for region T data would never find it and *maybe* could be skipped. I am not sure if trying to optimize in this way would be technically feasible, or more trouble than it's worth, but the concept exists.
BTW I retested C/Q/T on the same file, by doing X ALL and then FIND with various C/Q/T options. It appears to work correctly. So, I would say the non-N-type commands should all work.
If I say FIND ABC C Q T, it means to find ABC if it is either in a Comment or in a Quoted string, or in open Text - which is identical to searching for ABC everywhere on a line. Because it is in fact possible to return a result that meets that request, it is by definition NOT illogical. It is merely redundant. I believe your message is not reporting a real error, but amounts to sort of a "judgment call" - as if it is "illogical" to be redundant, and you are chastising the users. Do you really want to go there?
If you wanted to slap people's hands for being redundant, you could also do that for saying CHANGE ABC ABC ALL, or FIND ABC RED +RED ALL. Those commands are redundant too, but no one gets punished for asking. It's not a big deal, but unless your implementation code has an issue, it shouldn't break anything to allow it. Just saying. That's all the further I have on the matter.
|
|
|
Post by George on Feb 19, 2023 15:13:21 GMT -5
Robert: I will probably tackle the Nxxx commands, now that the 'normal' versions seem to be working. If users can figure out how to utilize them, well good for them. I know I will never tackle it.
As to the other stuff, redundant and illogical are different things. Illogical I still say needs a message. I think you previously have indicated on other topics that accepting operands, doing nothing, and not saying anything is just not good practice.
George
|
|
|
Post by mueh on Feb 19, 2023 15:14:19 GMT -5
George: When i tested the SHOW cmd i noticed that in msg "Showed 205 lines" the line nr is the nr how often search string is found . To test it issue SHOW INC all in _SPFLite.bas . FIND INC all issues msg "Chars INC found 205 times in 150 lines" Occures in all versions . Thanks for new feature P.S. Same for ULINE and REVERT but not for APPEND FLIP EXCLUDE all handled in pCmdEXCLFLIPSHOW
|
|
|
Post by Robert on Feb 20, 2023 0:58:54 GMT -5
I confirmed the results. SHOW XXX ALL will show the number of times XXX was found, but the message says the number of lines.
If possible, the SHOW message should provide the same information as FIND ALL. If that can't be done, SHOW ALL should correct the message.
However, since SHOW *is* in fact showing the number of times, it seems likely that revising the message to conform to how FIND shows it ought to be possible. The "fast" way to implement SHOW XXX would be to stop at the first found string, but evidently SHOW is finding every occurrence on each line, otherwise it wouldn't know how many were found.
|
|
|
Post by George on Feb 20, 2023 9:58:05 GMT -5
MUEH: Robert: Corrected. I can't provide the same message style as FIND. SHOW, along with 8-10 other Primary commands, is performed by one common routine, and it's structure just doesn't work the same. But the count will now be correct.
George
|
|
|
Post by mueh on Feb 20, 2023 12:22:59 GMT -5
George: I think you missed my update 4 hours ago in my previous update . 23051 fixed problem for SHOW but not for ULINE and REVERT . Thanks
|
|
|
Post by George on Feb 20, 2023 12:28:09 GMT -5
MUEH: Yes, missed that addition, I'll go check then out as well.
George
[UPDATE] Corrected - next Beta [/UPDATE]
|
|
|
Post by Robert on Feb 20, 2023 13:12:12 GMT -5
I have the 23.051 beta. Everything seems to be working fine.
I regret to say I still have issue with that message. Right now, it says,
All 3 operands (C Q and T) together is illogical
The "illogical" part aside, it seems like "3 operands" is kind of vague. What kind of "operands" are being referred to? That is important, because this feature is new, and it deserves an actual name for it.
I would like to propose a rewording that maybe we could agree on. This will also give the "operands" a "name". And, you know how I like good names. Here goes:
Using all area qualifiers C Q and T on one command is disallowed
The C Q T codes are used to "qualify" which areas of the file can be searched. It dispenses with the question of whether doing this is illogical or not; it simply says that you can't do it - certainly a true statement. And, "area qualifiers" has a nice ring to it.
Are you good with this?
|
|
|
Post by George on Feb 20, 2023 14:36:23 GMT -5
Sure, I'll go with that, Linda likes your wording better. How do I fight that?
George
|
|