[NOT A BUG] Parsing of Lua function

[Yincognito]

This is interesting since it became apparent to me when dealing with both Lua parsing, multiple argument functions, quotes / apostrophes, substitutes and obviously nested variables...

...\@Resources\Script.lua:

Code: Select all

function Result(text, othertext, numberone, numbertwo)
  print(text)
  return text
end

...\Skin.ini:

Code: Select all

[Variables]

[Rainmeter]
Update=1000
AccurateText=1
DynamicWindowSize=1
BackgroundMode=2
SolidColor=0,255,0,255

---Measures---

[Script]
Measure=Script
ScriptFile=#@#Script.lua
UpdateDivider=-1

[Text]
Measure=String
String=It's
RegExpSubstitute=1
Substitute="^(.+)$":"[&Script:Result('[&Text]',' not correct like this',2,1)]"
;Substitute="^(.+)$":'[&Script:Result("[&Text]"," not correct like this",2,1)]'
UpdateDivider=-1
DynamicVariables=1

---Meters---

[Result]
Meter=String
AntiAlias=1
MeasureName=Text
Text=Result = %1
;Text=Result = [&Script:Result('[&Text]',' not correct like this',2,1)]
UpdateDivider=-1
DynamicVariables=1

For simplicity, the script should simply return the first argument that was given to it, but it doesn't. Without the apostrophe it does. I let some alternatives in the comments, which produce either the same (wrong) result, or worse (errors). Didn't test if it also happens for "normal" (i.e. not inline) Lua. I tried to use [[ ]] literal syntax to pass the problematic argument to the Lua function, but naturally, since square brackets mean something else in Rainmeter, it didn't make any difference for the better. Escaping using \" in Lua doesn't make much sense since it's about apostrophes and they exist in the strings from my actual scenario. I guess one could just replace apostrophes with something else and avoid the whole thing or come up with other workarounds specific to the use case, but those won't fix the issue itself.

[Brian]

This isn't anything to do with lua per-se....but it is how Rainmeter is "determining" a string argument from a number (or nil/true/false).

Basically, when Rainmeter is parsing the string, it replaces [&Text] with It's, which results in:
[&Script:Result('It's',' not correct like this',2,1)]

The parser then tries to split 'It's',' not correct like this',2,1 into separate arguments. Since commas are perfectly valid when located between matching quote pairs, the results ends up a single argument.

The fix for this particular example is to use double quotes, which you attempted to do in the Substitute. That won't work though since the Substitute parser will also suffer from a mis-matched quote issue. In this case, you need to use double quotes in the commented-out Text option in your Result meter. (You may also need remove the Substitute on the measure as well.)

Code: Select all

[Text]
Measure=String
String=It's

---Meters---

[Result]
Meter=String
AntiAlias=1
Text=Result = [&Script:Result("[&Text]",' not correct like this',2,1)]
UpdateDivider=-1
DynamicVariables=1

However, you may run into the same problem if the original string contains a double quote. "
But this works (because of matching double quotes within the string):

Code: Select all

[Text]
Measure=String
String=It's "complicated"

---Meters---

[Result]
Meter=String
AntiAlias=1
Text=Result = [&Script:Result("[&Text]",', but correct',2,1)]
UpdateDivider=-1
DynamicVariables=1

Note: Original string has double quotes within the string, and there is an extra comma within the single quoted string. But it won't work if only 1 double quote mark is used.

-Brian

[balala]

EDIT: Whoops, Brian was quicker and more precise, obviously. Sorry...

A dev is definitely needed, however a properly altered substitution in the [Text] measure can do the job: Substitute="^(.+)$":"[&Script:Result("[&Text]",' not correct like this',2,1)]".
Not a fix, true, but maybe there is no fix at all. Or not even an error, just something related on how lua works? Don't know...

[Yincognito]

Thank you very much, using double quotes all around like you both suggested does indeed allow single quotes (i.e. apostrophes) to be present in the string. It looks like I only guessed half of this in my 1st commented alternative, because I wrongly assumed that single quotes would be needed to enclose the inline Lua after : since it itself contained double quotes and the pattern before : was also between double quotes (basically, I was in error trying to follow a similar advice from the manual, i.e. the last paragraph here).

I will probably need the Substitute in the measure so I can't yet remove it, and will most likely not have double quotes in the string itself (this is a field extracted from an .xml retrieved by WebParser in the actual scenario), so things will be adjusted along the lines mentioned by balala for the time being (though further adjustments might be performed when it comes to the final version).

Thank you, Brian, for the excellent explanation, it's clear now that this is technically not a bug (as in some omission, mistake or code issue internally), but rather a consequence of the limited ways one can handle / escape various quote types in a code that involves them in almost every part of it. I was so certain when classifying it as a bug earlier because I thought the inline Lua parameters were in some sort of "sandbox" when it comes to parsing (basically forgetting that first they had to be parsed by Rainmeter before being sent to the Lua module) and didn't take into account all the ways quotes can be used to workaround this.

P.S. Sorry for the delay in responding, had to attend a birthday event today, and the whole thing lasted longer than expected.