#419 tripping on tags within tags

[Lee Worden]

The following structure is defeating WW's parsing:

<source-file filename="Makefile">
outer.wikitext : Makefile
    echo '<project-file filename="inner.wikitext"/>' > $@
</source-file>

It gives me this kind of thing:

Warning: Tag <source-file filename="Makefile" project="File Locking 1"> is missing its closing tag in page 'File_Locking'
Warning: Unmatched </source-file> found on page ‘File_Locking’.

It looks like the project-file tag is causing it to terminate the source-file content prematurely, and then the closing tag is seen as an error because it's already terminated the tag. This is a problem, because there's a legitimate need to put this kind of thing within source files.

[Andrei Akhmetzhanov]

If I put <nowiki>...</nowiki> inside, then it works well (although it does not look nicely)

I thought I had the same problem with perl yesterday, but it seems to work now. So, at least one can do that using perl

link: http://lalashan.mcmaster.ca/theobio/lab/index.php/Test_page_1

[Lee Worden]

Wow, I never would have thought of that. I might use that as a workaround to get this immediate job done.

But as WW maintainer, I also need to fix this bug.

[Lee Worden]

PS. Please report things like this when you find them, if you can! If I don't hear about them, I can't fix them.

[Lee Worden]

These warnings come from function WWStorage::find_project_files_on_page(), which is the main workhorse function for extracting WW tag contents from wiki pages.

That function reads through the page text from beginning to end, taking each opening or closing tag in order. When it finds an opening tag, it looks ahead for the next opening or closing tag, and if it the thing it finds doesn't match, it emits this "missing its closing tag" warning and forces the tag to close just before the mismatched tag that follows it. (Oddly, there's a comment at this part of the code saying it avoids matching self-closing <project-file/> tags, which clearly isn't accurate.)

I think this strategy may have been adopted because of a problem where an opening source-file tag with its closing tag missing would swallow up the rest of the page and confuse people. It seems to me like the ideal strategy would:

• warn when there's an unclosed <source-file> tag, as close to the opening tag as possible, and with as little disruption to the rest of the page as possible.
• allow source file text to contain arbitrary wikitext, including WW tags nested within
• match what the MW parser does when it's processing a page and passing tags to WW one at a time.

This is probably an impossible combination, unfortunately.

But now I've found the ticket that led to this strategy being adopted [#266], and I feel more comfortable about extending it to allow more things within a source-file (to the extent that it's possible).

(Note... See also the suggestion in [#184] that I should straight-up quit trying to locate the tags in pages, and somehow let the MW parser handle it for me, since it does that when it's parsing pages in the first place.)

[Lee Worden]

I think a good step would be to clarify exactly what the MW parser does in mixed-up cases like these.

[Andrei Akhmetzhanov]

Ok, I will do. Thanks, Lee.

I have a relevant issue with another tag. For example, if I write
<project-file filename=manuscript.pdf linktext="Generated PDF"/>, it would be OK.

But what if I want to make my link bold, then if I write
<project-file filename=manuscript.pdf linktext="<b>Generated PDF</b>"/>
or
<project-file filename=manuscript.pdf linktext="Generated PDF"/>
it would give me an error in the first case

Warning: Tag <project-file filename="manuscript.pdf" make=no linktext="<b> is missing its closing tag in page 'Tumor_progression_modeling/Manuscript/Notes/CNRS_Report'

and just prints '''Generated PDF''' in the second.

Ex: http://lalashan.mcmaster.ca/theobio/lab/index.php/Test_maxima

[Lee Worden]

OK! I think the problem with putting a bold tag (or any other tag) in the linktext is a problem with the MediaWiki parser and not likely to go away.

The part with triple quotes is an issue in WorkingWiki - it's using the linktext exactly as it receives it without parsing it from wikitext to HTML. So this could be fixed if it's desirable. I'd recommend opening a separate ticket for it.

On the other hand, that would allow you to use linktext containing triple quotes, but not HTML-style tags, line breaks, or much else. For general-purpose project-file links, you need to use the single-bracket link syntax and the fullurl template, as in the makefile links at http://lalashan.mcmaster.ca/theobio/projects/index.php/WorkingWiki/Using_LaTeX_in_WorkingWiki/The_LaTeX_makefiles. Using that you can write whatever kind of link text you want. [Note... I think we will have easier ways to do this, without fullurl, after we upgrade the wikis to MediaWiki 1.21.]

[Andrei Akhmetzhanov]

Regarding yesterday problem and being inspired by http://youtu.be/RTxtiLp1C8Y?t=24m55s I can propose to write

<source-file filename="Makefile.mk">
outer.wikitext : Makefile
 echo '<''project-file filename="inner.wikitext"/''>' > $@
</source-file>

Then it might work

[Lee Worden]

Yes, that should work. Thanks, good suggestion - and looks like a fun and useful video.

And working around the bug is fine, but I'm also hoping to fix the bug, so we don't have to work around it :)

Actually, the kind of suggestions you're posting might be of interest to more people: consider posting them on http://lalashan.mcmaster.ca/theobio/projects/index.php/WorkingWiki/Tips_and_Tricks?