|
|
Post by Stefan on May 22, 2024 9:06:33 GMT -5
George,
SPFLite 24091 and later - not sure when this started
I can't fathom why, so this may apply to commands other than NEXCLUDE as well...
(1) Edit a random file (2) Issue a command like NX A (with or without quotes - it doesn't matter)
=> SPFLite will exclude all lines except those that contain the letter A
Now issue the same command from a macro, say NXtest.MACRO
00001 ' NXtest.macro
00002 SPF_Trace(ON)
00003 SPF_Cmd("NX A")
=> SPFLite will exclude only 1 line
|
|
|
|
Post by George on May 22, 2024 9:37:56 GMT -5
Stefan: I tried this with the 24069 production, and with the latest Beta and they both simply exclude 1 line. Same with the macro version.  ?? George |
|
|
|
Post by Robert on May 22, 2024 9:58:22 GMT -5
Just to be clear, NX (NEXCLUDE) finds and excludes lines not containing the find-string. That means NX is a FIND variant, and FIND without a qualifier like FIRST/LAST/PREV/NEXT/ALL defaults to FIRST. So does NX.
That means in your example, NX A will find the (one) FIRST line not containing "A" and will exclude it.
Thus, the issue you are citing is NOT a macro problem, because the NX A command issued by SPF_Cmd is doing exactly what it's supposed to to. If you wanted to exclude all lines that don't have A, you'd have to say NX ALL A.
Conclusion: The problem is on the command line, not in SPF_Cmd issued from a macro.
|
|
|
|
Post by George on May 22, 2024 10:15:34 GMT -5
Robert: But he is saying that an NX A on the command line is acting like ALL was coded, while the same command issued by a macro does not act like ALL was coded (i.e. correctly)
George
|
|
|
|
Post by Stefan on May 22, 2024 11:15:05 GMT -5
ARRRRGGGHHHH! My bad!
Stand down guys - I blame my ageing brain. Thx George, you saying that both exclude only one line gavemy brain the require kick up the rear.
I've found the difference between the two invocations of NX! In the NXtest.MACRO, the SPF_CMD("NX A") statement executes the 'real' NEXCLUDE (via its NX abbreviation) and is working as intended - exclude a single line. Turns out I also have a (long forgotten) macro called NX.MACRO. And when I manually enter the NX A on the primary command line, that invokes this NX.MACRO and not the 'real' NX/UNEXCLUDE command.
It so happens that the NX.MACRO actually effectively executes: SPF_Cmd("EXCLUDE ALL")
SPF_Cmd("FIND ALL "+Get_Arg$(0))
I built that many, many moons ago so that: (1) subsequent RFIND will jump to the various occurences, which it doesn't do if the initial command was UNEXCLUDE (2) because I never use NX without the ALL argument.
|
|
|
|
Post by George on May 22, 2024 11:49:36 GMT -5
Stefan: No sweat. I have been caught by the same thing many times. Sometimes not until I'm deep in a debug session with breakpoints set, variable watches etc. and then finally I smack the forehead and like you go - ARRRRRRGGGHHHH!!!!
George
|
|
|
|
Post by Robert on May 22, 2024 15:26:00 GMT -5
This isn't the first time that a macro overriding a built-in command has raised havoc. (George, remember when you kept installing an ALIGN.MACRO that had to be deleted for the ALIGN command to work right?) Perhaps if a means could be devised that wasn't too tricky, this whole thing could be handled differently. It's common in systems with macros to define a BUILTIN command so that you can always run the system defined command even if an overriding one exists.
I believe the idea is worthy of some consideration. IMHO, I think in most cases we would be better off not allowing an override of predefined commands. It just seems to cause so many problems, more than the seeming advantage of allowing it.
|
|
|
|
Post by George on May 22, 2024 15:50:23 GMT -5
Well, my preference would be to continue allowing a command to be overridden.
a) Sometimes, like Stefan's NX, it allows you to automatically specify optional operands that you always enter.
b) BUILTIN would be an item that some miniscule percentage of users would ever require. And even reading IBM's definition I'm not clear just how it is supposed to be used.
c) Maybe there could be some kind of visual signal that the command being run is a macro. God knows what?
George
|
|
|
|
Post by Stefan on May 23, 2024 8:23:23 GMT -5
George,
I agree that we should be able to override in-built commands for a variety of reasons. - Provide an abbreviation for an otherwise long-winded command - Accommodate common typos (e.g. I almost always type asve instead of SAVE)
- Simplify entry of a valid command (e.g. replace SHOW 10 20 with SHOW .10 .20 to show a line range instead of a column range)
- Add frequently used operands without changing the command abbreviation with which we are familiar - Extend an existing command to provide more functionality
- etc
If memory serves (sometimes it does, sometimes not), IBM required a DEFINE statement to re-assign a builtin name (say BROWSE) to a user macro (say MYBROW). When macro MYBROW executes and needs to call the 'real' BROWSE, it would need to specify BUILTIN BROWSE to avoid a loop with itself.
SPFLite doesn't allow macros to call other macros so the loop issue doesn't arise. (I mean of course you can via POST_DO, but to paraphrase Captain Barbossa "It's not gettin' to the next macro that's the problem... it's gettin' baaack")
SPFLite also differentiates between L and LOCATE and thus you can 'override' one without losing the other. Hence SET ALIAS.L=LOCATE TOP works while calls to commands LOC and LOCATE work like they always did.
I didn't use SET ALIAS.NX=NX ALL because I'm disappointed that RFIND doesn't work after an UNEXCLUDE command. (Command NX ALL <whatever> is functionally equivalent to EXCLUDE ALL followed by FIND ALL <whatever>)
This combination provides full RFIND support with the bonus of also highlighting all occurrences of <whatever>
I could have invoked the macro with SET ALIAS.NX=my_NX, an unnecessary complexity when a macro name overrides the internal command anyway.
Although that would have avoided 'raising havoc' (harsh) to which Robert refers. |
|
|
|
Post by George on May 23, 2024 9:11:04 GMT -5
Stefan: I agree. I'd still like a visual reminder it was a macro. How about something right under the Command > in the message line if anything in the previous attention interrupt invoked a macro. I'll experiment, see what it looks like.
George
[UPDATE]
Look for 24144 Beta -> Options -> General -> Display MacName on Message line
[/UPDATE]
|
|
|
|
Post by Robert on May 23, 2024 10:19:23 GMT -5
I believe there are a number of things that could be done, George, if you were of a mind to do them, and I don't see any of them as especially hard. (Like, not as hard as EFT was, for instance.)
If you are interested, I could put together a (brief, I promise) suggestion on what you could do with this.
R
|
|
|
|
Post by George on May 24, 2024 15:56:40 GMT -5
Robert: Hey! Suggest away!
|
|
??