This escapes all strings provided by add-ons server data to guarantee
they can't be used to get extraneous and potentially harmful HTML into
the generated web index.
However, and because I don't have time to look into the dense regex
contained in the relevant code right now, it also removes the hidden
feature of linkifying any URLs found in add-on descriptions. It's a
small price to pay for our safety, really.
An old add-on triggered a wmliterator crash with this comment:
#>>>> !!!!! REMOVE THIS AFTER TEST !!!!! <<<<#
The traceback showed that the crash came from the lua-stripping
code, which interprets "<<" as the start of a lua string. But below
it is code to remove quoted strings, and it doesn't crash, even
though there are cases where authors forgot to close a quote.
Two key differences stood out in the otherwise similar second
code: only looking for the endquote string in the text after
beginquote, and testing that endquote was less than 0, not -1.
Changing both gets the loop to terminate. Making it search the
text only after "beginquote+2" means that ">>" will no longer
be found, giving endquote a value of -1. But -1 is not less than
-1, so that must be changed to " < 0" to close the loop.
The problem: wmlscope assigns each file to a directory-based subtree, and
assumes that it is visible to every other file in that subtree. The intent
is that each campaign (or add-on of another type) will be in its own
subtree.
However, wmlscope/wmltools has derived these subtrees based on what
arguments get passed to wmlscope, rather than checking whether campaigns
have actually been split out. For instance, invoking wmlscope with
"../data/core ../data/campaigns <userdata>/data/add-ons" will cause
wmlscope to see three subtrees, one of which consists of all mainline
campaigns and another that includes all the user's add-ons. This leads to
many spurious "more than one definition/resource is visible here" errors.
A wildcard like "data/campaigns/*" would be expanded to all the individual
campaign directories. However, the wmlscope user might not know that they
should do that. Also, until the glob module was imported recently, globbing
did not work in the Windows cmd shell.
The solution: declare "campaigns" and "add-ons" to be roots, and check for
their presence in the directory names. If indicated, split out the
subdirectories into their own subtrees. Since it is possible that the user
may have moved, copied, or drafted campaigns/add-ons to another folder
that isn't following Wesnoth convention, also check for that.
While testing wmlscope without including data/core, which guarantees lots
of "unresolved" references, I got a crash pointing to this line with the
traceback: "NameError: global name 'args' is not defined".
At first, I thought the crash might have been caused by my splitting out
parse_macroref into its own function, several months ago. However, the
line is at the wrong indentation level for those "args" to be the variable
referenced here. So what "args" might have been intended?
After tracking down the commit that added "args=args" to this line, I've
concluded that this was simply a mistake. ESR isn't around to ask anymore,
but if a macro was never defined, or is not called correctly, what "args"
could be relevant?
The Windows cmd shell will not expand a globbed argument by default, in
fact it will make the argument invalid. Importing and utilizing the glob
module is needed for x-platform.
Globbing is especially important for breaking up the subtree, so wmlscope
doesn't give off "more than one resource/definition is visible here"
errors.
This option is pretty similar in effect to -v -v. Particularly now that
some new switches have been added recently, the clutter makes it no
longer worth keeping around.
A comment notes the option's disappearance, in case anyone wonders what
happened to it or how to get the same functionality.
Going back through wmllint's history, it turns out that there apparently
haven't been any "experimental conversions" since 1.4. Especially since
some new switches have been added recently, the clutter makes it no longer
worth keeping around.
A comment notes the option's disappearance, in case anyone is interested
in recreating experimental conversions again.
Fixes its help entry looking like this:
> --change-passphrase ADD-ON OLD NEW ADD-ON OLD NEW ADD-ON OLD NEW
> Change the passphrase for ADD-ON from OLD to NEW
When it really should look like this:
> --change-passphrase ADD-ON OLD NEW
> Change the passphrase for ADD-ON from OLD to NEW
