[v1.5.12.19] Curly braces escape character issue

[Pfeil]

In testing the new features in the latest beta, I tried to write the following to the log:

Code: [Select]

{test} \{test} {test\} {\test}\What I expected to see:

Code: [Select]

test {test} {test} \test\What actually printed:

Code: [Select]

{test} {test} {test} \test\

Now, through many permutations, this turns out to be the culprit:

Code: [Select]

{\
If that combination of characters is included, even with other characters between them, any curly braces before it will be escaped:

Code: [Select]

{test1} {hegthze} {test} {svsdv\regerger {} {test1} {hegthze} {test}Prints

Code: [Select]

{test1} {hegthze} {test} {svsdv\regerger  test1 hegthze test
However, if a "closing" brace is provided, again regardless of characters between them:

Code: [Select]

{test1} {hegthze} {test} {svsdv\regerger   fdghbfg} {test1} {hegthze} {test}Prints

Code: [Select]

test1 hegthze test svsdv\regerger   fdghbfg test1 hegthze test


[Gary]

What's happening is the odd combination of literals with tokens is making the parser think that it has finished.  Since it reprocesses for changes, it looks like it's malformed on subsequent iterations and just returns what it has. 

{test} \{test} {test\} {\test}\

Becomes 
{test} *test} {test* \test\  (* is used to show where literals are placed)

When the statement above is (re)run through the parser, it is malformed (in a token replacement sense... it appears to have a spurious { and that must mean that something is wrong with the data) and MUST stop (it doesn't make any assumptions about what else is in the statement).  The question then becomes, should it halt when things look malformed or does it just continue on and process everything else that it can?  I'm going to test with just reprocessing even if there's malformed information and see what it looks like.

That's a good catch, by the way.

[Gary]

Ok, so it wasn't a stretch to just, 'let it go' and continue processing.  Thinking about it, it's not that bad to just do that because, hey... this isn't financial or military software, right?

So, now if it just continues:

Code: [Select]

{test} \{test} {test\} {\test}\
becomes

Code: [Select]

test {test} {test} \test\
and

Code: [Select]

{test1} {hegthze} {test} {svsdv\regerger {} {test1} {hegthze} {test}
becomes

Code: [Select]

test1 hegthze test {svsdv\regerger  test1 hegthze test

[Pfeil]

hey... this isn't financial or military software, right?

Have you seen what people abuse Excel for? You never know where a versatile piece of software like VoiceAttack is deployed


Now, especially that any pair of curly braces, even empty ones, will be replaced, I have a question regarding the escaping of braces within variables, and outputting them as literal; Specifically, how is it done?

I have tried

Code: [Select]

Set Text [LiteralTest] to '\{EXP:1=1\}'
Set Text [Find] to '}'
Set Text [Replace] to '\}'
Write '[Blue] {TXTREPLACEVAR:LiteralTest:Find:Replace}' to log
And

Code: [Select]

Set Text [EscapeChar] to '\'
Set Text [LiteralTest2] to '\{EXP:1=1\}'
Write '[Blue] {TXTCONCAT:ExcapeChar:LiteralTest2}' to log
But either will return "1", because the "{EXP:}" token is processed at some point.

I presume it's stored as a literal brace in the text variable, but when it is retrieved using another token, it is processed from the inside out, so in this case it would have been "{TXTCONCAT:'\':'1'}", which to me doesn't explain why the "\" has gone missing("{TXT:EscapeChar}" prints "\" like it should)

[Gary]

Before I dive into that, I put a build out in, 'unofficial' that is different than the one you are using:

http://www.voiceattack.com/unofficial

Make sure that yields the same results, as it is doing things slightly different (for sanity's sake lol).

[Pfeil]

With that build(v1.5.12.20), the results are the same.


Though, rather worryingly, I'm getting a "UNABLE TO INVOKE PLUGIN. PLUGIN NOT VALID FOR THIS VERSION OF VOICEATTACK." error in the log.

I know you're working on the plugin system, I'm just letting you know in case that wasn't supposed to happen.

The plugin in question is pretty much the example plugin from way back, with the non-winamp section removed.

EDIT: Rolling back to v1.5.12.19 doesn't fix it(though that's supposed to have issues with plugins, apparently), though v1.5.12.11(which I happened to have a copy of) does.

EDIT#2: Properly rolled back to v1.5.12.16, which has no plugin issues either.

[Gary]

Weird... I've got various versions of plugins in my apps dir that still function.  If you want to send the dll over I can pop it in the debugger and see what's up.

[Pfeil]

Sure.

[BlackJack]

I would like to be quite specific: Before 1.5.12.19 it was possible to set a Path like this:

Code: [Select]

Set Text [EDLaunch] to 'E:\Games\EDLaunch'
Set Text [FileName] to 'netLog.123456789.01.log'
Write '[Yellow] {TXT:EDLaunch}\Products\elite-dangerous-64\Logs\{TXT:FileName}' to log
The result was:         E:\Games\EDLaunch\Products\elite-dangerous-64\Logs\netLog.123456789.01.log
But now it looks like:  E:\Games\EDLaunch\Products\elite-dangerous-64\Logs{TXT:FileName}

That means all commands which using this schema are not working any more.
What would be the easiest way to get these compatible to >1.5.12.19?

[Gary]

Yikes.  The escape sequence will need to be changed, because I'm not going to require everybody to do, '\\' just to get a path to work.

Good catch on that.   As a workaround at the moment, you could change your path to forward slash / if you are totally hosed up.

Any thoughts on a replacement escape character, guys?

|{ |}  or  ^{ ^}   or   ~{ ~}   (others?)


  /\ /\
((ovo))
()::)
  VVV

[Pfeil]

Yikes.  The escape sequence will need to be changed, because I'm not going to require everybody to do, '\\' just to get a path to work.

Ahem.

Because VoiceAttack generally works with tokens(and having "\" as an escape character would cause issues by itself), I suggest something like "{LIT:}", which tells the parser to treat the contents of the token as literal.

As you've explained the way tokens are parsed, I'm hoping it'd be possible to parse every token until only the "{LIT:}" tokens remain, and then parse those as the last step.

This also ties in to the ability to allow some processing to the contents of "{LIT:}", by passing it a parameter for the recursion depth: "{LIT:{CLIP}:1}" would parse "{CLIP}", but not its contents, and because the recursion depth is "1", the token would be converted to "{LIT:Contents of clipboard}", which would then tell the parser to leave that token and its contents alone until the final pass.

I made that suggestion also in part because it's difficult to pin down a certain character that's as unlikely as possible to conflict, uncommon, and yet can still be typed on most keyboard layouts.

Aside from that, the problem of escaping the contents of variables remains to be solved.
Even something like

Code: [Select]

Set Text [Test] to '\{test\}'
Write '[Blue] {TXT:test}' to logis currently impossible, it'll print "test" rather than the desired "{test}", and that's regardless of the escape character you choose.

I know I'm banging on about this, but I feel

Code: [Select]

Set Text [Test] to '{LIT:{test}}'
Write '[Blue] {LIT:{TXT:test}:1}' to log
Is a fair solution(though I realize the difficulty in combining it with parsing tokens from the inside out).

|{ |}  or  ^{ ^}   or   ~{ ~}   (others?)

"|" Is commonly used when dealing with Linux(pipe)

"^" Is used in Excel

"~" would be an issue because people use it instead of "±", so I could see "Value is ~{DEC:value}" happening.

While it may seem farfetched to encounter such characters, I feel especially in an assistive technologies context, and when using the clipboard, you can't know whether you will.

  /\ /\
((ovo))
()::)
  VVV

There's a certain irony in the fact that you didn't disable smileys there

[Gary]

I think I'm going to use the pipe | for this one.  It's unfortunate that it can't be a standard escape char \, but we do have a lot of paths going on.  I think the combinations of |{ and |} would interfere the least.

Ahem.
Quote from: Pfeil on September 19, 2016, 05:52:04 am
Because VoiceAttack generally works with tokens(and having "\" as an escape character would cause issues by itself), I suggest something like "{LIT:}", which tells the parser to treat the contents of the token as literal.

Yes.  Yes, you did (tell me so).



And the owl just looked so cute with his little sad, 'button'.

[Gary]

The latest beta changes \{ \} to |{ |}

That should take care of the path issue, Blackjack.



(>'-')> <('-'<) ^('-')^ v('-')v(>'-')>

[BlackJack]

Thanks, Gary. Now I am relieved. Really fast responding. As always!

[Pfeil]

Quick update on the plugin that no longer worked: It works again after updating to v1.5.12.23(from v1.5.12.19).

[Gary]

Ok, cool

[Pfeil]

An addendum to the non-working plugin: Editing an "Execute an External Plugin Function" action will pop up a "The plugin that is referenced by this action is not valid for this version of VoiceAttack." messagebox.

Despite that dialog stating "The plugin is available for selection, however, if you try to run this plugin, it will fail.", it does execute as expected.


For me personally it's not an issue anymore, as this finally motivated me to edit and compile the latest example plugin.