[BUG?]Quotes persist in Section variable function

[death.crafter]

Reviving this ancient bug yet again.

While working with fileview, the inline date function has type parameter. So, users might use quotes since it's a string. While I can set up functions to strip off the quotes, I think it should be done by default. So, I changed MeasurePlugin to achieve this.

I'll open a pr along with the fileview one.

[Brian]

Sorry it took so long to get to this.

The "PairedPunctuation" you mentioned from the code base is not stripped during the parsing function because other parsing functions need the punctuation to determine "type". The math parser needs the parenthesis to determine if the string is a formula. Quotes are needs for the Script measure to determine the type of the parameter (string, number or boolean). Plugin arguments are about the only place where we send all arguments as strings. We decided to let the plugin author deal with striping any quotes of the arguments.

As far as the issue when a missing quote happens, I would say that is technically a malformed parameter. While it might make sense in some cases to have a parameter with only 1 quote for whatever reason, trying to accommodate all possibilities is going to get difficult quickly. Right now we don't "escape" any characters like this, so using the character reference as jsmorley suggested might be the best way of sending 1 quote as an plugin argument.

-Brian

[death.crafter]

Sorry it took so long to get to this.

The "PairedPunctuation" you mentioned from the code base is not stripped during the parsing function because other parsing functions need the punctuation to determine "type". The math parser needs the parenthesis to determine if the string is a formula. Quotes are needs for the Script measure to determine the type of the parameter (string, number or boolean). Plugin arguments are about the only place where we send all arguments as strings. We decided to let the plugin author deal with striping any quotes of the arguments.

As far as the issue when a missing quote happens, I would say that is technically a malformed parameter. While it might make sense in some cases to have a parameter with only 1 quote for whatever reason, trying to accommodate all possibilities is going to get difficult quickly. Right now we don't "escape" any characters like this, so using the character reference as jsmorley suggested might be the best way of sending 1 quote as an plugin argument.

-Brian

You don't necessarily have to change the tokenizer. I had a little fix in my pull request. You could make that change in MeasurePlugin.cpp.

Also, there aren't any missing quotes.

The problem is, when we use [&x:SomeFunction("OneString", "TwoString", 'Three "String"')],
the actual parameters received by SomeFunction is
"OneString", "TwoString" and 'Three "String"'
instead of
OneString, TwoString and Three "String"

[Brian]

You don't necessarily have to change the tokenizer. I had a little fix in my pull request. You could make that change in MeasurePlugin.cpp.

Right. And your fix in the PR would work just fine if we were going to fix it. However, any fix would prevent strings with multiple quotes contained both within the string along with leading and trailing quotes.

Example: [SomePlugin:SomeFunction("String1" and "String2", SomethingElse)

The fix would replace "String1" and "String2" with String1" and String2 (missing leading and trailing quotes) which might be undesirable, depending on what the plugin does. This is why we will leave the strings as is, and let the plugin author handle how they want to deal with quotes.

Also, there aren't any missing quotes.

Sorry, I wasn't clear in what post I was referring to. It was this one: https://forum.rainmeter.net/viewtopic.php?t=38504#p198147
I just meant that a leading quote at the beginning of one parameter without a matching quote is somewhat malformed, and doesn't mean the parser would "go back" to after the first quote and continue to parse until it hits the delimiter again. If that makes sense.

-Brian

[death.crafter]

Example: [SomePlugin:SomeFunction("String1" and "String2", SomethingElse)

That's why we got single quotes for.

[&Some plugin:SomeFunction('"String1" and "String2"', SomethingElse)]

You need quotes of you want to include an comma in a string. And those quotes getting passed as part of the string isn't desirable.

If you had a string like ("Hello, this is a string), it would be sent as "Hello, this is a string, instead of logging am error, or being sent as "Hello and this is a string.

It's flawed, but well, as long as we don't need it it's not a bug.

And using a character reference isn't an work around cause it doesn't work. It's converted to a comma and then parsed as a comma. About including a single quote in the above example string, I would say rainmeter parser lacks an escape feature.

[Brian]

This has been fixed for the next release.

-Brian

[death.crafter]

This has been fixed for the next release.

-Brian

Thanks a lot again!