[WeiDU] Syntax Highlighting should handle double variable references appropriately

[4Luke4]

As you can see, the outer %% are highlighted as if they were content of the string... You could use another color to distinguish the outer pair from the inner one....

[burner1024]

What does this syntax mean?

[4Luke4]

What does this syntax mean?

Full code here.

DEFINE_PATCH_FUNCTION GET_DIRECTORY
STR_VAR
    location = ""
    locbase = ""
    locabs = ""
RET
    directory
BEGIN
    PATCH_IF ("%locabs%" STRING_COMPARE "") BEGIN
        TEXT_SPRINT directory "%locabs%"
    END ELSE BEGIN
        TEXT_SPRINT directory ~%mod_root%~
        PATCH_IF ("%locbase%" STRING_EQUAL "") BEGIN
            PATCH_FOR_EACH loc IN component_loc local_loc location BEGIN
                PATCH_IF  (~%%loc%%~ STRING_COMPARE ~~) BEGIN
                    TEXT_SPRINT temp EVALUATE_BUFFER "%%loc%%"
                    TEXT_SPRINT ~directory~ EVALUATE_BUFFER ~%directory%/%%loc%%~
                END
            END
        END ELSE BEGIN
            PATCH_IF ("%location%" STRING_EQUAL "") BEGIN
                TEXT_SPRINT directory "%directory%/%locbase%"
            END ELSE BEGIN
                TEXT_SPRINT directory "%directory%/%locbase%/%location%"
            END
        END
    END
END

Basically, %loc% evaluates to component_loc, local_loc, and location, where each of those variables have their own value... So you need a double reference.....

[burner1024]

So this double evaluation actually works? I remember it not being that easy. And is there a point in using another color for the external pair?

[4Luke4]

So this double evaluation actually works? I remember it not being that easy.

Well, I expect it to work since DavidW uses it when SCS compiles SSL files... I also have that function in my mod, but I'm not currently using it....

And is there a point in using another color for the external pair?

No, there isn't. I mean, I suggested it because it'll probably allow for better visual identification, but it is by no mean strictly necessary....

[burner1024]

Painted it red.

[4Luke4]

Painted it red.

What if there are more than two levels (e.g., %%%%%test%%%%%)?! Well, it's probably not important, I'm not sure you can do something like that....

[burner1024]

I don't know. When someone submits a request and shows actual live code doing this, then I'll see.

[4Luke4]

@burner1024

I think I've just found out an edge case (see the attached screenshot...)

[burner1024]

Hmm... Not sure how to resolve it. Probably will need some recursion, but I think syntax definition won't color them differently in that case. I'll have to think. If you want to take a shot at this, https://regex101.com/ is your friend.

[burner1024]

Does weidu actually resolve all references recursively? I was under impression that EVAL only adds one level of resolving: EVAL ~%%%%my_var%%%%~ = ~%%my_var%%~

[4Luke4]

Does weidu actually resolve all references recursively?

Dunno, sorry... Wisp knows it for sure, you might want to ask him....

[burner1024]

From the docs:

EVALUATE_BUFFER variable | User variables inside the given string are evaluated one additional time.

BACKUP ~1/backup~
AUTHOR ~1~
VERSION ~1~

BEGIN ~1~
OUTER_SPRINT test1 ~test0~
OUTER_SPRINT test2 ~test1~
OUTER_SPRINT test3 ~test2~
OUTER_SPRINT test4 ~test3~
OUTER_SPRINT test5 EVAL ~%%%%test4%%%%~
PRINT ~%test5%~

$ weidu --nogame 1.tp2 --yes --no-exit-pause
[weidu] WeiDU version 24600
1.TP2  0  0 Installed

Removing old installation of [1] first ...
uninstall: 1.tp2 0
Will uninstall   0 files for [1.TP2] component 0.
Uninstalled      0 files for [1.TP2] component 0.

SUCCESSFULLY REMOVED OLD [1]

Installing [1] [1]

%%test2%%

Saving This Log:
1.TP2  0  0 Permanently_Uninstalled
1.TP2  0  0 Installed ~1~

SUCCESSFULLY INSTALLED      1

So essentially there are only 2 meaningful levels of % chars, and all the rest are literal part of the string. Consequently, they should be colored as such. I think it should be doable.

[burner1024]

The problem is that regex engine finds %entries% in EVAL ~%entries%_%idx%%~ first, and then parses the rest independently.

@FredrikLindgren could you lend us your wisdom? How does WeiDU parse the EVAL string - with regex or some other method?

[FredrikLindgren]

You may be taking on more than you can reasonably solve here. WeiDU can use any character as a variable delimiter (cf. EVALUATE_BUFFER_SPECIAL), and % is only a variable delimiter inside of a string. %foo% is a string, because used outside of a string, % is a string delimiter.

Yes, WeiDU uses regexps. I'm not sure it's any use to you but:

For each evaluation, WeiDU does an iterative forward search for the variable-regexp, which is normally %[^%]+%. The string length is traversed once and when no more matches can be found, evaluation is complete. This means one evaluation pass can evaluate, for instance, ~%foo%_%bar%~ in one pass and expand both %foo% and %bar%, but if you nest variables, like in ~%%foo%%bar%%~ you need an additional pass for each level of nesting. So evaluation is not recursive.

So essentially there are only 2 meaningful levels of % chars, and all the rest are literal part of the string. Consequently, they should be colored as such. I think it should be doable.

That's because you only request two levels of evaluation. If you run OUTER_SPRINT test5 EVAL EVAL EVAL ~%%%%test4%%%%~, the result will be test0.

[burner1024]

You may be taking on more than you can reasonably solve here. WeiDU can use any character as a variable delimiter (cf. EVALUATE_BUFFER_SPECIAL), and % is only a variable delimiter inside of a string. %foo% is a string, because used outside of a string, % is a string delimiter.

Mostly this is what I'm trying to determine - what we can reasonably solve. Certainly not going to fancy EVALUATE_BUFFER_SPECIAL. We're talking about %s inside strings here. I think double evaluation is a common enough use case to be worth the effort, but anything more complicated probably isn't.

That's because you only request two levels of evaluation. If you run OUTER_SPRINT test5 EVAL EVAL EVAL ~%%%%test4%%%%~, the result will be test0.

You can EVAL EVAL EVAL :)? Better put it into manual, wish I'd knew this 15 years ago.

[burner1024]

OK, I think I found something that works, more or less:

@4Luke4 Any more use cases?

[4Luke4]

That's because you only request two levels of evaluation. If you run OUTER_SPRINT test5 EVAL EVAL EVAL ~%%%%test4%%%%~, the result will be test0.

Does the same hold for EVALUATE_BUFFER_SPECIAL?

You can EVAL EVAL EVAL :)? Better put it into manual...

Yeah, I definitely agree.

[4Luke4]

@4Luke4 Any more use cases?

None for the time being....

[burner1024]

Published a new version.

[4Luke4]

Published a new version.

I'm sorry, but it's not working as expected...

Another example:

[burner1024]

I need the text

[4Luke4]

I need the text

SET opcode = (VARIABLE_IS_SET EVAL ~effects_%idx%_op~) ? EVAL ~effects_%idx%_op~ : ~-1~

OUTER_TEXT_SPRINT sslvariables ~%sslvariables%&%variables%~

One more:

COPY ~.../mymod-inline/%script%.ssl~ ~%workspace%~

[burner1024]

please test

[4Luke4]

please test

There are still some issues....

TEXT_SPRINT EVAL ~effects_%idx%_%v1%~ ~%v2%~

[burner1024]

Well, there's lexical ambiguity for you. If %_% is a var, then it's colored correctly. These cases aren't distiguishable without actually compiling the script.

[4Luke4]

Well, there's lexical ambiguity for you. If %_% is a var, then it's colored correctly.

Yeah, that's precisely my case. In fact, the real variables are %idx% and %v1%.....

[burner1024]

It's either this or just color all % the same, without trying to guess their meaning at all. I'm leaning towards the first option for now, although it may change after using it in the wild for a while. What do you think?

[4Luke4]

It's either this or just color all % the same, without trying to guess their meaning at all. I'm leaning towards the first option for now, although it may change after using it in the wild for a while. What do you think?

OK, let's try this new option for now....