Cannot add Inventory_Window_2 plugin. Or any plugin for that matter.

Okay, so recently I tried adding the Inventory_Window_2 plugin from here:(http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=9574)
and followed all the steps here, however when I go to add it, I get an output of:



I for the life of me can't get it to install or load in any way. On top of that no plugin at all will load. So I think it might be something in my settings, but I'm not sure.

I'm running the Aardwolf version of MUSHclient 4.98 on Windows 8.1.

Any help would be much appreciated!

It's not you. That plugin is in error.


That's definitely an invalid Lua escape sequence that goes ignored by PUC-Rio Lua 5.1 but is flagged as invalid by LuaJIT (which gets bundled with the Aardwolf package instead of PUC-Rio Lua 5.1) because invalid escape sequences are often indications of secretly incorrect expression patterns.

You either want to change that line to:

or

Depending on the original intent. I'm guessing probably the first one?


That seems quite exceptional and unlikely. What other plugins did you try?

The Reference Manual seems silent on what is the effect of \x where x is not in their listed series of characters that "can" be used.

I would expect that \x where x does not have a defined effect would result in x, so that you don't have to remember whether to escape things, like single quotes inside a double-quote literal.

In particular:



The second-last line there appears to indicate that the "defined" behaviour (if you count what the source actually does as the defined behaviour) is to accept any "non-special" character after a backslash and treat it as the non-escaped version.

So, the escape sequence is not "ignored" (which implies it is omitted) but treated like I would expect: \x is x if x does not have another definition.

---

Plus I think it is naughty of LuaJIT to introduce a different behaviour to what the official source does.

Well, this behavior changed between PUC-Rio Lua 5.1 and 5.2, so they also decided that erroring on invalid sequences is the right thing to do.

The reference manual is silent on a number of things that end up being dangerous in practice, like how to perform rounding when passing floats into string.format %i. (Which I think we just recently saw an instance of in the forum?)


That's dangerous. It means you can accidentally and silently fail to escape something in your regex pattern, leading to an entirely different pattern. Better to be told that you've done something wrong so you can fix it right away instead of introducing a silent bug.

Yes, but Lua regexps are escaped with "%" and not backslash, so that problem doesn't exist to a great extent.

Lua "patterns" escape with %. Not quite the same.


Whaaaat?? That problem is exactly what caused OP to make this thread. The mentioned plugin has a regex with ambiguous intent and dubious functionality. Can you actually say what the correct fix is here? Can you even say if the plugin in its original form was working correctly because of this escape mistake? I can't. I can only guess.

Sure I can.



The (unnecessary) backslash before the { and } should be treated as not being there. This is what Lua 5.1 does.

Your use of LuaJIT is what caused him to make the thread, not his string management. That is a side-effect.

Neither of us has any reason to believe that the author intended for that behavior given how it's written. All you know is how the engine interprets the string, but you have no idea if that interpretation is the proper one at all. In fact, I think it might be the wrong one. Curly braces are a special character in a regex pattern and should be escaped when intended to be literal, which means the slashes should be doubled, not ignored, because they are not unnecessary, because the curly braces are meant to be literal in the regex pattern not literal parts of the string that contains the regex pattern.


LuaJIT (Lua 5.2, actually) is just making the error in the plugin apparent instead of silent. The plugin was in error from the start, but Lua 5.1 hid that, leading to potentially erroneous behavior instead of an error message.

You are confusing PCRE regular expressions (where both backslashes and curly braces have meanings) and Lua regular expressions, where neither do.

http://www.gammon.com.au/scripts/doc.php?lua=string.find

If you look at http://www.lua.org/manual/5.2/manual.html you will see no mention of it being an error to have a backslash followed by one of the non-explicit escaped characters. Indeed it says:



Thus you could argue that under that "default" rule that "\{" should actually represent "\{" (itself), and not raise an error.

I cannot see any reference to this change in behaviour in the section "Incompatibilities with the Previous Version".

Note to script-writers: I am not supporting Lua 5.2, as they made many changes to many things, include the way environments work. Things like serialization which use setfenv will not work. Thus I have stuck with Lua 5.1.

From the reference (link above):

Not at all! Be clear that I am not talking about string.find or any other string.foo. Lua's string library does not use regular expressions; it uses Lua simplified patterns. There are things you can do with regular expressions that you can't do with Lua's patterns.

MUSHclient does, however, use PCRE matching for triggers and also includes Lua PCRE. When dealing with actual PCRE regular expressions (like with wait.regex for example!) it is very very important to make sure that the patterns are expressed accurately and unambiguously. OPs plugin fails to do that, and Lua 5.1 just silently trucks along without revealing the author's mistake.

The problem is that both PCRE and Lua strings both have their own separate literal escape steps. OP's plugin seemingly intends to escape the braces at the PCRE level, not the Lua string level, and it failed at this. We should ask first "Why would the author try to escape curly braces in a string?" The answer is that he wasn't. He was trying to escape curly braces in the next-level-down PCRE expression. Stripping the slashes would thus violate the author's actual intent and produce a PCRE that matches something unintended.



That's true. I chalk that up to a documentation error, because accurate documentation is hard. The interpreter's behavior did change between 5.1 and 5.2, though (You can verify this at http://www.lua.org/cgi-bin/demo and http://trylua.org/). And for the above stated reasons, I believe the particular change to be a very good one.
The difference should of course have been documented, but you're right that it isn't.


Good. I don't think anyone wants that as it would break too much good code.
Note, however, that OP's particular issue is not breaking good code but rather suddenly highlighting bad code.

Oops. You are right about it being a PCRE regexp. I got the idea into my head it was a string.find and once it was there it stayed there. :)

You are right about the possible confusion with the backslashes in a PCRE regexp, which are the devil to get right in Lua, particularly if you are doing them in the "Send" box where you need four backslashes in a row to get a single backslash into the PCRE engine.



Indeed, as documentation is often done after the event, and quite probably by someone other than the coder. Still, I call it a bug when the code and the documentation don't match. If you documented the "+" symbol to do subtraction when it really does addition, perhaps the code is wrong and not the documentation?

Personally, these days, I update the documentation as soon as I have made a code change (and tested it).