Wiki syntax issue with [ ] characters

[Emmanuel Blot]

Browsing a wiki page I wrote 6 months ago, I discovered that the wiki parsing has been slightly modified so that:

new_channel_name [, '''integer''' handle [, '''boolean''' test]]

is rendered now as

new_channel_name [, integer handle [, boolean test]]

I'm not sure if this can be considered as a bug or if I should always prefix the [ character with an escape character (!).

Feel free to close this ticket if this syntax is now considered as invalid.

[Emmanuel Blot]

This looks like a bug: the escape syntax is neither usable, as it prevents the content of the bracket to be interpreated as wiki syntax, i.e. the bold characters in the previous examples are not properly rendered:

new_channel_name ![, '''integer''' handle [, '''boolean''' test]]

is rendered as

new_channel_name ![, integer handle [, boolean test]]

I'm increasing a little bit the severity.

[Christian Boos]

Well, yes, that's because of [3376]. In [3382], I reverted the way we supported MoinMoin's style ["internal free links"], in the Wiki's IWikiSyntaxProvider, as that was made redundant by the generic change done in [3376].

Certainly a better way to handle this situation would be to leave the generic TracLinks handlers as they were before [3376], and do everything in the Wiki's IWikiSyntaxProvider, so that:

• only [WikiPageNames] or [WikiPageNames with label] would link to wiki page names
• then, [arbitrary ''content'' like the '''above'''] would be rendered as normal wiki text, as before
• the shortcut syntax for arbitrary WikiPageNames would still be the MoinMoin's ["internal free links"] style

[Christian Boos]

So nobody objects to making the [xyz] syntax more strict, as suggested above?

[Emmanuel Blot]

To be honest, I'm kinda lost here, I don't really understand the pros and cons of your proposition.

[Christian Boos]

Well, I'll try to summarize the different options (examples of simple TracLinks, but it's a similar situation with labelled TracLinks):

1. before [3376]:
   1. [WikiPageNames] → [WikiPageNames]
   2. [nonwikipagenames] → [nonwikipagenames]
2. after [3376]:
   1. [WikiPageNames] → WikiPageNames
   2. [nonwikipagenames] → nonwikipagenames
3. suggested:
   1. [WikiPageNames] → WikiPageNames
   2. [nonwikipagenames] → [nonwikipagenames]

2.1. seems to be like an intuitive enhancement, so I'd suggest to keep it (proposition 3.1)

2.2. is the troublemaker change, as shown in this ticket's description. It makes writing stuff like [etc.] turn into links, and conflicts somehow with changeset shortlinks (see notes in WikiPageNames). I propose to revert to the old behavior (that's proposition 3.2).

For the situations where athomas wanted to have a quicker way to refer to a Wiki page not following the WikiPageNames conventions, there's still the ["nonwikipagenames"] syntax, which is convenient enough, IMO.

[Matthew Good]

It seems rather pointless to write "[WikiPageNames]" when you can just write "WikiPageNames". I'd rather see [3376] reverted.

[anonymous]

Replying to mgood:

It seems rather pointless to write "[WikiPageNames]"

Sure, I should have taken the labelled links as examples. e.g. [WikiPageNames the wiki page names]. What do you think about the above example?

[Christian Boos]

Fixed in [3535:3536].

I removed support for arbitrary Wiki links like [this] or [anything is a link]. It's still possible to write ["this"] or ["anything is a link"], though, and I think that's convenient enough.

But #3240 is still supported, i.e. one can write [WikiPageNames the wiki page names] to get a labelled link and not having to write the wiki: prefix, when the target is a WikiPageName.

I was not sure if it was worth to support the following: ["arbitrary page name" arbitrary label].

If you think so, I can still add support for that later (i.e. post 0.10).