Wiki syntax should be enforced (for ticket comments)

[Emmanuel Blot]

When the wiki syntax is not valid (missing closing tag, for example: ''italic'), Trac does not fix it up.

Although this is not a strong issue with Wiki pages that can be edited and fixed by human beings, it starts to become an issue with ticket comments: the missing wiki tag - which is translated to an XHTML missing tag - propagates across the whole ticket and may corrupt the whole page.

As ticket comments cannot be edited, the only current way to recover from such a simple user mistake is to tweak the SQL DB ;-(

IMHO, Trac should ensure that such an error does not propagate outside a comment, i.e. should always close any open tag along with the end of a comment.

It is worth noting that when post-commit hooks are used -such as the one from the /contrib dir- the user may not even notice than "his" wiki syntax is not correct, as it is never rendered from his subversion client (commit message).

[Emmanuel Blot]

Example of ticket page rendering, when one of the comments is short of a closing italic/emphasis tag

[anonymous]

Can you post the exact comment which was causing this? I can't reproduce the issue.

[Emmanuel Blot]

Sure. From sqlite3:

sqlite> select * from ticket_change where ticket=670 and time=1149159330;
670|1149159330|souquiej|comment||(In [575]) Refs #670
 * dyntest: ''sga:mdraw'' renamed to ''sga:drawm''
 * dyntest: new ''sga:adrawm' command, exercised in drawbat.dtf

There are remaining comments after this one, but the display misbehaves starting after the missing "'" char.
If it can help, the server runs [3320].

[Christian Boos]

Ok, thanks, I could reproduce the problem. This is apparently because of the unfinished italic being in a list.

I wanted to implement anyway a more robust block-level elements and inline-level elements stacking algorithm, but this will have to wait 0.11.

I will nevertheless check if there's a simple fix for this specific problem, for 0.10.

[anonymous]

What if I want to have apostrophes in my italic text? How do we avoid false positives trying to "fix" the user's formatting?

[Christian Boos]

The fix will be at the HTML level, not touching the wiki text. In the above example, the last "'" character will stay as is, simply the <i> tag will be closed.

[Manuzhai]

There seems to be consensus that this can wait for 0.11.

[Christian Boos]

#4702 was closed as duplicate of this one.

[Christian Boos]

WikiEngine refactoring and related fixes postponed.

[anonymous]

It would be nice if comments could be edited somehow; then one could at least work around the kind of problem discussed here.

[Emmanuel Blot]

Replying to anonymous:

It would be nice if comments could be edited somehow; then one could at least work around the kind of problem discussed here.

There is a dedicated ticket for this feature (#454), please do not deviate the thread from the original topic.

[Emmanuel Blot]

#5771 marked as a dup.

[Christian Boos]

#6344 was closed as duplicate of this ticket.

[Christian Boos]

#8520 reports a few more examples of this behavior.

[Christian Boos]

#8661 was closed as duplicate of this ticket.

[Christian Boos]

Nice test case lifted from ​TH:4358:

This line '''does not close bold.

No problems though as it resets. Lists won't though:
 * '''Not closing bold...
 * Bold Continues here...

This will be bold too as will the rest of the page...

While the big changes I mentioned in comment:3 (4 years ago, really?) are definitely still not on the radar, that specific issue seems simple enough to be addressed in the current formatter.

[Christian Boos]

Fixed in r8886.

Fixing the one-liner formatter fully would indeed be a bit more work, as we currently process the whole content in one go without the ability to detect natural paragraphs. But as the resulting xhtml is still well-formed, it's not a big deal and not preventing this ticket to be closed.