Breaks when special characters (like , or [[) in message

[riot]

If you try to add a comma or other special characters like a link inside a NoteBox, either the message will be broken off or (in case of [[) only half of the text will be displayed entirely without notebox.

I tried enclosure in ", ', """ - yet nothing helped. Some overeager parser trying to split macro arguments here, maybe?

[riot]

Change: better summary.

PS: Can someone change the reported by field to my username? Probably less spam, that way. Sorry.

[Ryan J Ollos]

Following [10070], we using parse_args from the Trac API for parsing the input arguments. It should be useful to take a look at the documentation: ​here. [11211] might have improved the situation as well. I'm currently testing r11211 in a dev environment with Trac 0.11.0.

Based on my testing, the only character we need to escape is a comma, and it must be escaped with a backslash. I'll add some documentation to the wiki page about this.

The following example works fine for me:

[[NoteBox(tip,Hey\, you know you can use the `[[NoteBox]]` macro for many things!!! ! @ # $ % !^ & * ( ) - + = [[. '''Don't''' worry about special chars\, they are no problem! Just escape your commas \\, and backslashes \\. Everything else will be interpreted as normal wiki markup.)]]

The problem you could run into though, is that everything in text passed to the NoteBox macro is interpreted as wiki markup. So if you put the text [[NoteBox]] in your sentence, it will render a warning just as it would in any other location in a wiki page.

Please reinstall the latest version and send me the specific markup if you can produce a situation that doesn't yield the expected results.

I'm resolving this is worksforme for now, though your report may have been valid prior to [11211].

[Ryan J Ollos]

I've found a situation that doesn't work. It doesn't appear to be possible to embed macros within macros. For example,

[[NoteBox(tip,You can even put a [[NoteBox(note,!NoteBox)]] within a !NoteBox)]]

However, to address this situation, I think it needs to be fixed in the Trac API. I vaguely remember reading about this in a Trac ticket. I'll make a note to investigate this and open a ticket in Trac if no one has brought this up already. As noted, I'm testing with Trac 0.11.0, so this could even have been improved already in a later version.