Previously, the string only needed to match part of the macro. However, this
left too much room for unintended matches. This change is also quicker for
wmllint to process.
After a line ending in a '+', the C++ parser ignores any number of newlines,
wmlparser2 only ignored a single one. This case did not appear in mainline.
This moves the after the fall schedule into core to grant that the
debian package wesnoth-editor does not depend on wesnoth-utbs.
Also, the images now life in their own subdirectories.
Wmllint has been updated to take care about the changed paths.
Although we can now auto-recognize characters in the core NAMED_*UNIT macros,
campaigns may have their own recruit/recall macros. This comment will tell
wmllint which field contains the macro's id.
The basic format is 'wmllint: whofield <macro> <num>'. This commit sets up the
dictionary, the next commit will actually parse the macros. It will explain
more details about how to use this magic comment in wmllint's introduction.
Although this is not a core macro (yet - I've been meaning to ask why Wesnoth doesn't have core recall macros), it is used in many UMC projects in a consistent format, making it a de-facto standard. Test that the macro has only one field, to make sure it isn't deviating from the format.
If we have a regex match for the macro, we parse it and see if it meets key tests:
* There are at least 7 arguments parsed (NAMED_UNIT can have extra WML).
* The original regex could also match UMC macros, like "Attack of the Western Cavalry"'s NAMED_SHIP_UNIT. To make sure that such macros are following the format of the core macros, we check that the side, x, and y fields are numbers, or variables/macros consistent with those fields.
* Also make sure that the id field isn't blank. Not only would adding an empty id to the list of present characters be pointless, that list is added to spellings, and zero-length entries crash the spell-check.
If all those tests are passed, we append the id argument to the list of the present.
I also tweak the wording in the intro about the "wmllint: recognize" magic comment to reflect that wmllint is now recognizing ids in some macros.
As it was, the code was excluding all quotes from arg, even in translatable strings. Although this did not break any code that uses the args, I don't care for that behavior.
During testing, I found that spaces inside quotes were preserved by the "instring" code, but not spaces inside naked parentheses. For example, "(Elvish Rider)" would be turned into "ElvishRider". This fix keeps interior whitespace from being discarded; the problem of leading and trailing whitespace is dealt with by stripping the arg before appending it to args.
This will keep non-core usage types from being described as a "non-standard usage class" in recruitment error messages. These error messages will only be triggered if there is a mismatch between recruits and recruitment patterns, so this magic comment is low-priority.
It was suggested that wmllint could auto-detect new usage values in unit files, and automatically append them to the list of recognized usage types. This was rejected because of the possibility of adding misspelled or mistaken usage types.
When recruitment patterns include bogus usage classes, it will trigger a message during the consistency check. However, this check won't tell you whether your problem is with the usage classes or the recruits. For example, if you get a message that "no light fighter units are recruitable", your first thought might be that you didn't include a light fighter unit in the recruit list. The message doesn't clue you in directly that the light fighter simply doesn't exist in mainline.
Now a clause will be added to the message when non-mainline recruitment classes are involved, alerting designers when bogus usage classes are involved, but mild enough that it hopefully won't scare away authors legitimately seeking to use custom classes.
This replaces the old usage check. The next commit will add a magic comment for appending custom usage types.
The convention that [textdomain] uses "/translations" is strongly established, and I can't think of a legitimate reason for an add-on not to be following it.
The binary path check is a crude test. The names that took hold for menu image directories are "/public" and variations of "/external*", so we look for those strings. It does not catch the worst case of all - when all binaries are outside the campaign define, not just a set-aside directory.
I first thought of these checks while brainstorming ways to use the in_textdomain and in_binary_path code in hack_syntax(). However, realizing that these checks did not really hack any syntax, I wanted to find someplace in the sanity checks where the code would fit. I finally found it.
While there are many places that wmllint assumes that "#" begins a comment, from Vultraz's description it sounded like parse_attribute was being used to find the attribute's value, and then a string_strip was done on the value. So I looked for the direct cause in wmltools.
Again, the solution is to look for whitespace to precede the hashsign.
Incidentally, I don't know why the original code had the first "where -= 1", then had value and comment go from [:where+1] and [where+1:].
I had a hunch that the hash would be the problem, because I realized that wmllint usually just looked for '#' to figure out if a line contained a comment, and that this also matched pango color coding. My wmllint backslash/userdata commits used this same re.split match to prevent this false positive.
(It won't prevent all unintended matches, e.g. "Guard #4", but I don't think that can be helped.)
The problem came, I believe, when the old line interacted with the block ten lines down:
elif eligible.count('"') % 2:
dostrip = not dostrip
The value's closing quote was on the other side of the split.
Here's the rationale for these additions:
* There is so much focus on wmllint's role in conversion, that many people may not think of it as a validator also (I didn't). So often, stumped authors ask in the forums about problems that would have been fixed or pointed out if they'd run wmllint. I want to encourage awareness of wmllint as a validator.
* Folded a line to fit normal 80-width CLI.
* Help contained no mention of this rather redundant option.
* How many people don't realize that ESR's long introduction is there?
* Some users may not understand why they're being dumped back to wmllint's help.
I used "inconsistency" for the actual variable name, because "known" seems more likely to be accidentally reused.
I pondered whether to allow the scenario check to go forward, but decided to just make a clean break.
Note that this does not prevent any of the information-gathering for the consistency check, just the check itself.
Why would you want to use this option? Of course, you should run the consistency check at some point. But if you simply want to recheck if you've fixed all the bugs in your campaign, you might not want to have wmllint slog through data/core again.
According to the introduction, stringfreeze does *not* suppress the warning, and the code bears this out.
I wonder how often this option is actually used.
I realized that as it stood, my dictionary would linger, bad if wmllint were being run on multiple campaigns. A special unwho keyword, 'all', clears the dictionary.
