|
|
Post by Stefan on Jun 15, 2022 9:39:10 GMT -5
Hi Guys,
NEXCLUDE (NX) basically "finds" a string and excludes one (or more) lines that do not match from the display. And I'm willing to bet that NX is rarely issued without the ALL keyword. So in terms of its function, NX is basically a FIND command, albeit one that also plays around with the line display. I've always preferred NX <string> ALL over FIND <string> ALL for the simple reason that 99.9% of the time I don't need to see the occurences 'in context', ie. surrounded by lines which do not include <string>.
NX <string> ALL is functionally equivalent to the command sequence EXCLUDE ALL ; F ALL <string> Both display the same results, except that the EXCLUDE+FIND sequence will (profile permitting) highlite the <string> occurences, and one can use RFIND to step through the occurences.
NX does neither. And it's frustrating that RFIND cannot be used after what is effectively a FIND command in disguise.
Hence I'd like to suggest that
(a) the search-string used on an NX command should be available to the RFIND command to allow users to 'step' through the file, AND/OR, (b) the search-string used on an NX command should be highlited (profile permitting).
I appreciate that SPFLITE provides a number of way of skinning this cat, e.g. (assuming Robert's wish for a separator char in SET commands is granted)
- a SET ALIAS.NX = EXCLUDE ALL ; F ALL =1
- a SET ALIAS.NX = X ALL =1 ; FLIP ALL
- a NX.MACRO
|
|
|
|
Post by Stefan on Jun 16, 2022 3:15:03 GMT -5
Hi Robert, Good shout about including several =n parameters in the SET command. This leads me to another idea... How about allowing =A (or =.) in the SET statement to reference 'all parms' entered with the ALIAS command ?
In terms of my use case, the FIND ... MX approach isn't helpful because I DO want to see the lines which contain the <searchstring> and MX does the opposite, it excludes them. In this case, FIND ... MX ALL is effectively equivalent to X ... ALL. From a user perspective, a NX ALL 'ABC' request displays lines with ABC in them and exclude all other lines. Given that ABC could occur anywhere along the lines, they may not all be 'obvious'. This is where the highlighting would help draw the user's eye to the ABC occurences. Similarly, given that some longer lines may need to be scrolled left/right to get to ABC, the ability to 'step through' the results with RFIND would be very useful. As it stands, NX supports neither highlighting nor RFIND support.
I take the point about NX finding LINES rather than STRINGS, but one could argue that so does FIND. Both search for a user-supplied string to select/position cursor at certain lines.
|
|
|
|
Post by George on Jun 16, 2022 8:41:32 GMT -5
Stefan: While I appreciate what you'd like with NX ALL "ABC", please understand that all the NX/NF style searches do not simply use the normal search routine and then simply 'reverse' the handling.
When the negative searches were introduced, that's exactly what I attempted to do. A miserable failure. The normal search routine does way more than is normally realized, handling high-lighting and the MX/DX etc. requests, setting pointers up for future CHANGE / RFIND / RCHANGE / RJOIN / RSPLIT requests (a definitely non trivial task). Trying to crowbar in the negative search to ths code did nothing but screw up all the original support.
Adding code to spot multiple occurrences per line, and doing the high-lights is a significant change to the code as right now there is no internal "keep looking even though you've found the string" . Why? There's just no need, a line either has or does not have the string.
BTW: NX does support repeat finds - do an NX "ABC" and then walk through subsequent occurrences with (RLOCFIND)
George
|
|
|
|
Post by Stefan on Sept 10, 2022 12:56:05 GMT -5
OK, I appreciate the technical constraints. Time for another little MACRO ditty.... I use the NX command a lot - mostly in the NX ALL <something> form, which excludes all lines except those with <something> in them. After such an NX command, RFIND or RLOCFIND (habitually assigned to PF5) will not 'step' from one occurence of <something> to another.
To circumvent this, I use X ALL followed by FIND ALL <something> a lot.
String them together with a ; (command separator) and things work ok, but it's a lot of typing (prone to finger trouble).
If you don't string them together, you need to press the (Home) key as well, because X ALL unhelpfully leaves the cursor on the single "Excluded Lines Marker" rather than the command line. So all this becomes a little clunky.
Answer to both issues: NXA.Macro
' NXA.MACRO
'-----------------------------------------------------------------------------------------
' This is Edit Macro NXA Stef 08/09/22
'
' Without operands, it performs "X ALL" but leaves the cursor on the command line.
' With operands, it performs like "NX ALL <operands> but allows the RFIND/RLOCFIND (PF5)
' commands to operate as usual afterwards.
'-----------------------------------------------------------------------------------------
LOCAL AS STRING args$ = Get_Arg$(0) ' Capture operands as usual
If INSTR(UCase$(" "+args$+" ")," ALL ") > 0 THEN _
args$ = Replace$(args$," ALL ",WITH " ") ' Remove the "ALL" keyword if any
IF args$ = "" THEN
SPF_Cmd("EXCLUDE ALL") ' Exclude all lines
ELSE
SPF_Cmd("EXCLUDE ALL") ' Exclude all lines
SPF_Cmd("FIND ALL "+Get_Arg$(0)) ' Find whatever user wants
END IF
Halt(Get_RC,Get_Msg$) ' All done
Try NXA <something> on a file with several lines containing <something> dotted about. Press PF5 (RFIND) a few times. Greatly improves my productivity.
|
|
|
|
Post by Stefan on Sept 13, 2022 11:34:32 GMT -5
R, Ermmm... yes. X ALL followed by FIND ALL xxx is exactly what NXA macro does.
In my post on 10 Sept, I was sharing the SOLUTION which I decided to adopt after George spellt out the technical constraints which prevents changes to SPFLite to implement my initial suggestion. I accept that the code won't be changed and hence shared a macro which others may find useful.
Perhaps you mistook my 10 Sept post as continuing to labour the issue. By the way, in a philosophical way, your statement Of course it won't step to an occurrence of <something>. RFIND repeats a search for a thing that was FOUND. Since NX locates (NOT FINDS) lines that do NOT have <something", that action cannot be repeated.
makes no sense in a "human" context.
In order to "...locate (NOT FIND) lines that do NOT have <something>...", NX ALL <something> MUST look for <something> to determine which lines NOT to EXCLUDE.
So the last thing SPFLite effectively "searched" for (and found) was <something>.
To a human, this is semantically indistinguishable from FIND <something> As a human, I asked SPFLite to FIND occurences of <something> and exclude all other lines, and the NX command does exactly that.
Now I appreciate that you and George may well have intended X and NX as a commands that exclude lines and thus think of them as "working on lines". Effectively when a <string> argument is present. they are 'search functions in disguise'. And I note that when X <something> will exclude a line, a subsequent RFIND DOES indeed exclude the next matching line. It's just NX that is diffferent.
But as I said, I accept the constraints as George explained. No issues.
|
|
