Wookee/Problems

Report problem pages here. If it's just a case of fixing Wiki markup, edit them with a description such as "Wookee me!" to bump them in Recent Changes.

1  Smileys

UT Vertex Animations From MilkShape – Smiley parsed in wrong place

Enclose it in <nowiki>...</nowiki>. I could also remove the =) shorthands for smileys (using = for their eyes), but I've occasionally seen them used.

just seen it elsewhere too. ":p" is a problem, as it occurs in names and urls. Could you change it so " :p" parses instead? – Tarquin

I'd rather make it that the :-)-like smiley shorthands (as opposed to :rolleyes: and the likes) always require a non-character in front of them. —Mychaeel

sounds good. – Tarquin

Done. —Mychaeel

2  Table syntax

• [HUD mutator]?

  This syntax seems to cause problems within a table. (Found in Canvas)

  it's the pipe character in the link

  But that's the correct link markup, isn't it?

  yup, it's correct link markup. Houston, we have a problem!

  Correct link markup, but paragraph markup has precedence. Will think about it. Enclose the cell with the link in <wiki>...</wiki> meanwhile. (By the way: Why does <p> have a margin above it?)

  erm.... oops. – Tarquin

  Can we change that (have the margin below the <p> rather than above it)? Same for <ul> (<ol> works as expected, apparently – see forum). —Mychaeel

  changing it now, will be uploaded in a few mins. just realised why I did it that way – so P+P could have a smaller top margin, there's no way to do it the other way around. – Tarquin

• Another feature with unexpected outcome: Using || ---- in a separate paragraph to generate a cell spanning two columns with a line in it is interpreted as an appendage to the last table cell (nested paragraph formats). Another thing to think about... (using || <wiki>----</wiki> serves as a workaround meanwhile).
  • I've been abroad Saturday and Sunday (and I was very tired when I returned yesterday evening), but I managed to spare some time to think about a couple of Wookee-related things.
    1. Table cells shouldn't take nested paragraph markup without a <wiki>...</wiki> around it. This way they'd even be able to interpret || ---- as "insert a horizontal separator line."
       • Done, without the special | ---- handling (yet?). In addition, tables whose first row ends in a | are formatted as 100% wide and with borders/cell backgrounds (needs some CSS).
    2. <pre> should return as a Wookee block that displays its content verbatim.
       • <code> is back as block-level markup (so you can't use it within a paragraph; you'll need to use <tt><nowiki>...</nowiki></tt> for that). Verbatim paragraphs (those starting with whitespace) get their character markup parsed again. —Mychaeel
    3. I'll slightly change the architecture of the Paragraph base class to simplify the implementation of paragraph markup that requires the use of separators in the middle of a paragraph (like ; ... : and | ... |). This way character markup and this separator could coexist much more gently so that [[blah|bleh]] won't create two table cells anymore.
       • Done. Tables with Wiki links in them behave nicely now.

         Mych Tarq

         bleh!

• What about tables with and without borders: see Wookee/Suggestions

3  Wiki links

I've just realised that this:

[[some text

creates a link if it's the last thing on a line. bug or behaviour? – Tarquin

Feature of course, though not necessarily recommended practice on part of the authors. Open tags are automatically closed when the paragraph ends. (Just like the '' I left open in this one.) —Mychaeel

the hash sign in headings

on the page Shoot One, Shoot Two, Shoot Three, the hash sign is used in headings thus:

 === properties for Trigger #2 ===

Presumably the hash sign is meant to be human-readable to stand for "number", however, Wookee thinks it should number the heading. It puts a number at the front of the heading and removes the hash sign:

4  properties for Trigger 2