Hey @zep,

I'm not sure if this is related to the last += parser bug. It doesn't seem to be, but if it is, it's possible you already fixed it in your dev version.

Having a tab as whitespace in this construct:

t={1}
t[1]    +=1

-- (with visible whitespace)
t={1}
t[1]⟼+=1

Produces an "unexpected symbol near +" error.

I copied the "see what the pre-parser does" trick to clipboard:

printh([=[t[1]  +=1]=], "@clip")

And got this when I pasted it back into an editor

t[1 ]    =   + (1)  

-- (with visible whitespace)
t[1·]⟼·=·⟼·+·(1)··

Note that it only seems to do this if the left value is a table deref. Mind you, other complex lvalue patterns might also trigger it.

Maybe your regex needs some "\s*" patterns where it currently only has " *"?

I'll assume this is enough for you to go on. :)

...oh, and one tiny, itty-bitty, almost-not-worth-mentioning afterthought, since you're mucking with that code...

It'd be awful cool if this worked:

x,y += 64,64

just sayin' ;)

Thanks @Felice, great catch -- this is fixed for 0.2.2d

x,y += 64,64 is syntactically too complex for the preprocessor, sorry! It works only for a limited set of simple transformations, but the bugs that have surfaced along the way show that a more general, elegant solution would have been worth it (i.e. parsing and manipulating the ast) -- next time!

Credit to @Newton17 and @nemo_dev on Discord for finding it, actually. :)

But yay! Thanks! :)