|
Post by Robert on Jul 6, 2024 10:43:38 GMT -5
This looks very nice. It contains all the features I have been talking about. I think this would be very useful. No objections at all.
R
|
|
|
Post by mueh on Jul 6, 2024 11:06:18 GMT -5
Hi George ! This .Current-label syntax has all fetaures except LABEL .AA which should allow to clear label in line selected . ( only opne of .AA .10 .zfind format specified ) . Thanks
|
|
|
Post by Robert on Jul 6, 2024 11:32:59 GMT -5
Mueh, if you want to remove a label located at .AA you can issue this:
LINE "." .AA
I just tested this and it works
R
|
|
|
Post by mueh on Jul 6, 2024 11:48:20 GMT -5
Robert: Yes i know but LAB .AA it's easy to type .
|
|
|
Post by George on Jul 6, 2024 12:01:12 GMT -5
MUEH: Just to be clear, you want LAB .AA to clear .AA if present. Correct?
|
|
|
Post by Robert on Jul 6, 2024 12:49:43 GMT -5
Mueh, George:
Internally, any "label" value that is "unassigned" or "invalid" is zero, represented as 0 or .0. So, if LABEL command is used to "assign" a label, a syntax consistent with this understanding would do it:
LABEL .AA 0 ----- or ------ LABEL .AA .0
I think this is a syntax that is more clear as to what is happening. Using just LAB .AA seems to imply you want to define .AA as something or other - but what? It's important not to make commands so brief they are arcane.
R
|
|
|
Post by George on Jul 6, 2024 13:47:01 GMT -5
Sorry Robert, LABEL already has 'flavors' of valid syntax, one more like LABEL .AA is no big deal. Besides, it's done.
Face it, SPFLite already has commands that 'break' the rules, TAG, SORT, LOCATE etc. - what's one more?
George
|
|
|
Post by George on Jul 6, 2024 14:12:18 GMT -5
OK, 24188 posted. An early try at getting LABEL command updated. I think it all works but ....
+-- string-literal -- normal FIND type options ---------------------+ | | | | LABEL -- .target-label >-+-- .Current-label -------------------------------------------------+--> [ +|-nnn ---+ ---> | | | | | | +-- :tag -- [ NEXT | PREV | FIRST | LAST ] -- line-range-operands --+ | | ---- | +-------------------------------------------------------------------------------------+
Operands can be in any order BUT the 1st encountered .label becomes the .target-label. Other labels could be present in the string-literal and :Tag versions to specify a line range.
The only addition here is the option of entering a simple LABEL .label to remove a label from whatever line it is on.
|
|
|
Post by mueh on Jul 7, 2024 2:21:10 GMT -5
Hi George ! Installed 24188 (Title 24187) . User macro 'MI -' or f xxx +red fails with msg 'Operand: +red, exceeds the maximum +/- Adjustments' . 2 concern's . LAB .AA clears label . LAB .10 or .zfind is rejected . ( not necessary ) . Should clear label on that line . LAB .AA .zfind +1 is rejected . Adjustement can only be made on other label ( .BB ) . If interested here a sample macro which handles the 2 concern's with some curious syntax not requiring the dot for label . to test it execute cmd's at end of code . last cmd moves the label down to next occurence if repeated until .zfind is zero . LA.macro (2.11 KB) Thanks
|
|
|
Post by George on Jul 7, 2024 10:25:12 GMT -5
MUEH: Good comments, all should be fixable. As I said, an early try.
George
|
|
|
Post by Robert on Jul 7, 2024 10:29:05 GMT -5
George, I am ok with .LAB .AA removing label .AA. I would be hard pressed to object when you have been so accommodating already.
R
|
|
|
Post by Robert on Jul 7, 2024 13:53:39 GMT -5
George, in beta 21.188 (Windows title = 24.187.beta) I tried to add a label to line 4 like this:
LABEL .BB .4
I get msg:
Label: .4 is not valid
Seems like this should be allowed.
R
|
|
|
Post by George on Jul 7, 2024 15:29:31 GMT -5
Yes, The next version will resolve this kind of thing. There are two label lookup routines (for various reasons) and it hasn't been choosing the correct one consistently.
George
|
|
|
Post by Robert on Jul 7, 2024 15:38:04 GMT -5
I am thinking about how LABEL will get used in a macro.
Will you support things like this?
SPF_CMD("LABEL .BB !" + TSTR$(myLptr)) I am not familiar with how you process the ! notation that converts LPTR values to LNUM values, and if this would work here.
R
|
|
|
Post by George on Jul 7, 2024 15:39:52 GMT -5
Not sure, but it should work as it uses the standard line reference lookup.
George
[UPDATE]
It will NOW worl in the next Beta.
[/UPDATE]
|
|