Link to quoted name of relative wikipage fails

[mrelbe <mikael@…>]

Example: Create the page ParentPage/This is a child page

To link to this page on ParentPage, one would intuitively write:

[./"This is a child page"]

but the result is a link to the child page "This with the label is a child page"

Conclusion: quoting names of relative wiki pages is not correctly interpreted.

[Remy Blank]

There's a conflict here. Partial quoting is not supported, so the link should rather be ["./this is a child page"]. Unfortunately, this syntax is already taken for linking to a wiki page in MoinMoin syntax.

The new WikiCreole syntax for links allows doing what you want, though:

[[./This is a child page|Child page]] → Child page

See ​here for an example (if it doesn't disappear).

[mrelbe <mikael@…>]

Replying to rblank:

There's a conflict here. Partial quoting is not supported, so the link should rather be ["./this is a child page"]. Unfortunately, this syntax is already taken for linking to a wiki page in MoinMoin syntax.

But ["./this is a child page"] is currently rendered as ./this is a child page and not as this is a child page (which I was expecting).

Don't you think many users will be confused by this?

[Remy Blank]

You mean that we should automatically strip the leading "./" for relative page specifications? That would make sense, yes.

[mrelbe <mikael@…>]

Yes, that's exactly what I mean, and don't forget dropping "../" too.

[Remy Blank]

Ok, if this can be done easily I'll do it for 0.12, otherwise I'll postpone for 0.12.x.

[Remy Blank]

Actually, the [wiki:./ChildPage] syntax also doesn't strip the leading dot. I'll try to fix both.

[Remy Blank]

With [9513], leading "./" and "../" components are stripped from ["./ChildPage"] links.

Fixing the [wiki:./ChildPage] link properly is difficult, as it is currently not possible to differentiate it from [wiki:./ChildPage ./ChildPage] due to the label being generated outside of the wiki link formatter. So we have two options:

• Either we accept that [wiki:./ChildPage ./ChildPage] is rendered as ChildPage (that is, if the target and the label are equal, we assume that there was no explicit label).
• Or we don't strip leading "./" and "../" components from [wiki:...] links, as it is always possible to set an explicit label.

Thoughts?

[Mikael Relbe]

Here are my observations on Trac 0.12dev-r9513.

I have compiled some cases of wiki-links in the tables below. Each case is repeated for each possible variant, though some are obvious I did not remove any for the sake of completeness.

Each table contains the wiki text, the current rendering of the wiki (which may vary as this Trac site gets upgraded), the produced link name for r9513, the link name which I expected, and a comment whether I think the link name is correctly rendered or not.

You are welcome to disagree with me ;)

1: ./ChildPage

#	Wiki	Currently rendered link	Link name r9513	Expected link name	Comment
1.1	[./ChildPage]	ChildPage	ChildPage	ChildPage or Child Page	NOK*)
1.2	[./ChildPage ChildPage]	ChildPage	ChildPage	ChildPage	OK
1.3	[./ChildPage ./ChildPage]	./ChildPage	./ChildPage	./ChildPage	OK
1.4	["./ChildPage"]	ChildPage	ChildPage	ChildPage or Child Page	NOK*)
1.5	["./ChildPage" ChildPage]	ChildPage	-	ChildPage	NOK, plain text and link rendered: "["./ChildPage" ChildPage]", expected link name "ChildPage"
1.6	["./ChildPage" ./ChildPage]	./ChildPage	-	./ChildPage	NOK, plain text rendered: "["./ChildPage" ./ChildPage]", expected link name "./ChildPage"
1.7	[wiki:./ChildPage]	ChildPage	./ChildPage	ChildPage or Child Page	NOK*)
1.8	[wiki:./ChildPage ChildPage]	ChildPage	ChildPage	ChildPage	OK
1.9	[wiki:./ChildPage ./ChildPage]	./ChildPage	./ChildPage	./ChildPage	OK
1.10	[wiki:"./ChildPage"]	ChildPage	./ChildPage	ChildPage or Child Page	NOK*)
1.11	[wiki:"./ChildPage" ChildPage]	ChildPage	ChildPage	ChildPage	OK
1.12	[wiki:"./ChildPage" ./ChildPage]	./ChildPage	./ChildPage	./ChildPage	OK

^*) Link name is ChildPage even if [wiki] split_page_names = true in trac.ini

2: ./Child Page

#	Wiki	Currently rendered link	Link name r9513	Expected link name	Comment
2.1	[./Child Page]	Page	Page	Page	OK
2.2	[./Child Page Child Page]	Page Child Page	Page Child Page	Page Child Page	OK
2.3	[./Child Page ./Child Page]	Page ./Child Page	Page ./Child Page	Page ./Child Page	OK
2.4	["./Child Page"]	Child Page	Child Page	Child Page	OK
2.5	["./Child Page" Child Page]	Child Page	-	Child Page	NOK, plain text rendered: "["./Child Page" Child Page]"
2.6	["./Child Page" ./Child Page]	./Child Page	-	./Child Page	NOK, plain text rendered: "["./Child Page" ./Child Page]"
2.7	[wiki:./Child Page]	Page	Page	Page	OK
2.8	[wiki:./Child Page Child Page]	Page Child Page	Page Child Page	Page Child Page	OK
2.9	[wiki:./Child Page ./Child Page]	Page ./Child Page	Page ./Child Page	Page ./Child Page	OK
2.10	[wiki:"./Child Page"]	Child Page	./Child Page	Child Page	NOK
2.11	[wiki:"./Child Page" Child Page]	Child Page	Child Page	Child Page	OK
2.12	[wiki:"./Child Page" ./Child Page]	./Child Page	./Child Page	./Child Page	OK

3: ../SiblingPage

#	Wiki	Currently rendered link	Link name r9513	Expected link name	Comment
3.1	[../SiblingPage]	SiblingPage	SiblingPage	SiblingPage or Sibling Page	NOK*)
3.2	[../SiblingPage SiblingPage]	SiblingPage	SiblingPage	SiblingPage	OK
3.3	[../SiblingPage ../SiblingPage]	../SiblingPage	../SiblingPage	../SiblingPage	OK
3.4	["../SiblingPage"]	SiblingPage	SiblingPage	SiblingPage or Sibling Page	NOK*)
3.5	["../SiblingPage" SiblingPage]	SiblingPage	-	SiblingPage	NOK, plain text and link presented: "["../SiblingPage" SiblingPage]", expected link name "SiblingPage"
3.6	["../SiblingPage" ../SiblingPage]	../SiblingPage	-	../SiblingPage	NOK, plain text presented: "["../SiblingPage" ../SiblingPage]", expected link name "../SiblingPage"
3.7	[wiki:../SiblingPage]	SiblingPage	../SiblingPage	SiblingPage or Sibling Page	NOK*)
3.8	[wiki:../SiblingPage SiblingPage]	SiblingPage	SiblingPage	SiblingPage	OK
3.9	[wiki:../SiblingPage ../SiblingPage]	../SiblingPage	../SiblingPage	../SiblingPage	OK
3.10	[wiki:"../SiblingPage"]	SiblingPage	../SiblingPage	SiblingPage or Sibling Page	NOK*)
3.11	[wiki:"../SiblingPage" SiblingPage]	SiblingPage	SiblingPage	SiblingPage	OK
3.12	[wiki:"../SiblingPage" ../SiblingPage]	../SiblingPage	../SiblingPage	../SiblingPage	OK

^*) Link name is SiblingPage even if [wiki] split_page_names = true in trac.ini

4: ../Sibling Page

#	Wiki	Currently rendered link	Link name r9513	Expected link name	Comment
4.1	[../Sibling Page]	Page	Page	Page	OK
4.2	[../Sibling Page Sibling Page]	Page Sibling Page	Page Sibling Page	Page Sibling Page	OK
4.3	[../Sibling Page ../Sibling Page]	Page ../Sibling Page	Page ../Sibling Page	Page ../Sibling Page	OK
4.4	["../Sibling Page"]	Sibling Page	Sibling Page	Sibling Page	OK
4.5	["../Sibling Page" Sibling Page]	Sibling Page	-	Sibling Page	NOK, plain text presented: "["../Sibling Page" Sibling Page]", expected link name "Sibling Page"
4.6	["../Sibling Page" ../Sibling Page]	../Sibling Page	-	../Sibling Page	NOK, plain text presented: "["../Sibling Page" ../Sibling Page]", expected link name "../Sibling Page"
4.7	[wiki:../Sibling Page]	Page	Page	Page	OK
4.8	[wiki:../Sibling Page Sibling Page]	Page Sibling Page	Page Sibling Page	Page Sibling Page	OK
4.9	[wiki:../Sibling Page ../Sibling Page]	Page ../Sibling Page	Page ../Sibling Page	Page ../Sibling Page	OK
4.10	[wiki:"../Sibling Page"]	Sibling Page	../Sibling Page	Sibling Page	NOK
4.11	[wiki:"../Sibling Page" Sibling Page]	Sibling Page	Sibling Page	Sibling Page	OK
4.12	[wiki:"../Sibling Page" ../Sibling Page]	../Sibling Page	../Sibling Page	../Sibling Page	OK

[Christian Boos]

Ok, so points 1.4, 1.7, 1.10 and 3.4, 3.7, 3.10 correspond to a real issue ([wiki] split_page_names = true not respected).

Points 2.10 and 4.10 will probably be fixed at the same time the above is fixed, although I would have been tempted to expect them to not respect split_page_names because of the "quoting" (but then, the quoting is usually not used for CamelCase page names, rather for linking to arbitrary WikiPageNames where split_page_names won't produce any effect as it's only splitting on CamelCase).

Points *.5 and *.6 correspond to #7695.

[Mikael Relbe]

The only problem with 1.4 and 3.4 is the disrespect of split_page_names (leading path is correctly removed).

1.7, 1.10, 3.7 and 3.10 have two problems: they disrespect split_page_names, and the leading path is not removed.

With 2.10 and 4.10 I only noticed the leading path problem, but these examples should too, I think, respect split_page_names though it is not demonstrated since the path itself contains a space in these examples.

My thoughts concerning expected link names is based on the assumption that the following four cases should yield the same link name, i.e., they should be equivalent from a wiki authors point of view, when wiki page name does not contain any space:

#	Wiki	Currently rendered link	Expected link name*)
a.1	PageName	PageName	PageName or Page Name
a.2	["PageName"]	PageName	PageName or Page Name
a.3	[wiki:PageName]	PageName	PageName or Page Name
a.4	[wiki:"PageName"]	PageName	PageName or Page Name

^*) depends on split_page_names

If this holds to be true (well, it is true), then I think the following should be considered equivalent too:

#	Wiki	Currently rendered link	Expected link name*)
b.1	[../PageName]	PageName	PageName or Page Name
b.2	["../PageName"]	PageName	PageName or Page Name
b.3	[wiki:../PageName]	PageName	PageName or Page Name
b.4	[wiki:"../PageName"]	PageName	PageName or Page Name

^*) depends on split_page_names

If you buy that, then I think the following should be considered equivalent as well:

#	Wiki	Currently rendered link	Expected link name
c.2	["../Page Name"]	Page Name	Page Name
c.4	[wiki:"../Page Name"]	Page Name	Page Name

All cases here will produce the link name "Page Name" when split_pages_names = true, under the assumption that leading paths shall not be part of the link name and that split_page_names shall always be respected.

Does this sound reasonable?

[Remy Blank]

Nice analysis ;-)

One small comment: [../PageName] and ["../PageName"] are not equivalent: the former can be any sibling resource of the resource containing the link (i.e. on this ticket, [../123] → 123 links to ticket 123), whereas the second is always a wiki page (["../123"] → 123 links to wiki page 123). It might be a bit counter-intuitive, but that's the current state.

So if we summarize, the issues are the following (I only mention ./ variants, but the same applies to ../):

1. ["./PageName"] doesn't respect split_page_names.
2. The syntax ["PageName" page name] is not supported.
3. [wiki:./PageName] doesn't remove the leading ./.
4. [./PageName] doesn't respect split_page_names.

I'm pretty sure 1. can be fixed easily, and 2. can be added easily as well. I'll do that.

3. and 4. share the same issue that when the label should be mutated, we don't have the information of whether the label was explicit or implicit. That's what I explained in comment:7. To pass that information along would require an interface or behavior change in the link resolvers of IWikiSyntaxProvider, e.g. adding something like an explicit_label that would be None if no label was provided. This could probably be implemented in a mostly backward-compatible way.

So, other suggestions for 3. and 4.?

[Mikael Relbe]

Replying to rblank:

Nice analysis ;-)

Thank you :D

Without knowing the details of the implementation (I've just scanned the code very roughly) I think it would be hard to obey split_page_names if the label is treated in an implicit manner. The example [wiki:./ChildPage ./ChildPage] from comment:7 would perhaps not easily be rendered as "./ChildPage", and not "Child Page", when split_page_names = True, which I would expect, unless treated explicitly as stated in comment:12 (at least I'm guessing that).

Please note that 3. in comment:12 also doesn't respect split_page_names.

[Remy Blank]

2. above (#7695) was fixed in [9535].

[Remy Blank]

Actually, I was wrong in comment:12, and 4. was easy to fix at the same time as 1. Both are fixed with [9536].

Now on to the difficult part…

[Remy Blank]

Generate nice labels for [wiki:./PageName] links.

[Remy Blank]

The patch above fixes the [wiki:./PageName] links as desired. The solution is quite hackish, but fully backward-compatible:

• Added fullmatch to the arguments passed to the resolver, if the latter can handle it. Funnily, there were already a few resolvers that had an optional fullmatch argument (ticket, report, log), but I couldn't find a place where they were called with that argument. Maybe they were leftovers from a previous implementation.
• If a link to a wiki page has no explicit label, and it isn't a relative link, and it isn't a wiki:PageName shortform, then a "nice" label is generated. We could even drop the last test and have wiki:"./PageName" be rendered as PageName, but this would be inconsistent with e.g. ticket:123, which is rendered with the ticket: prefix.
• The arity() function was fixed to report the arity correctly for methods. Previously, it would count the self argument, so the behavior would be different if a resolver was a function or a method. I believe the new implementation is more useful, and shouldn't break too many plugins (only a single plugin on trac-hacks uses arity(), and only on a function, so it won't break).

So, yeah, I'm not exactly proud of the solution, but it's simple enough and works. I'd even drop the test for "shref" in link_resolver() so that wiki:PageName links are displayed nicely.

Thoughts?

[Mikael Relbe]

A quick reflection (I will return with more after testing the patch).

Replying to rblank:

• […] We could even drop the last test and have wiki:"./PageName" be rendered as PageName, but this would be inconsistent with e.g. ticket:123, which is rendered with the ticket: prefix.

No, don't do that, let wiki:./PageName be rendered as wiki:./PageName, and let [wiki:./PageName] be rendered as PageName. When an author states an explicit link, but omits to define a label, I think a "nice" label shall be generated. But not for implicit links as wiki:./PageName.

Consistency is important, I think.

[Mikael Relbe]

I have now tested the patch 9239-wiki-labels-r9536.patch​, applied on Trac 0.12dev-r9536, and all issues in comment:9 are sorted out!

For the sake of formality (and documentation), here are my observations for:

Link name (False): [wiki] split_page_names = False
Link name (True): [wiki] split_page_names = True

1: ./ChildPage

#	Wiki	Link name (False)	Link name (True)	Comment
1.1	[./ChildPage]	ChildPage	Child Page	OK - fixed!
1.2	[./ChildPage ChildPage]	ChildPage	ChildPage	OK
1.3	[./ChildPage ./ChildPage]	./ChildPage	./ChildPage	OK
1.4	["./ChildPage"]	ChildPage	Child Page	OK - fixed!
1.5	["./ChildPage" ChildPage]	ChildPage	ChildPage	OK - fixed!
1.6	["./ChildPage" ./ChildPage]	./ChildPage	./ChildPage	OK - fixed!
1.7	[wiki:./ChildPage]	ChildPage	Child Page	OK - fixed!
1.8	[wiki:./ChildPage ChildPage]	ChildPage	ChildPage	OK
1.9	[wiki:./ChildPage ./ChildPage]	./ChildPage	./ChildPage	OK
1.10	[wiki:"./ChildPage"]	ChildPage	Child Page	OK - fixed!
1.11	[wiki:"./ChildPage" ChildPage]	ChildPage	ChildPage	OK
1.12	[wiki:"./ChildPage" ./ChildPage]	./ChildPage	./ChildPage	OK

2: ./Child Page

#	Wiki	Link name (False)	Link name (True)	Comment
2.1	[./Child Page]	Page	Page	OK
2.2	[./Child Page Child Page]	Page Child Page	Page Child Page	OK
2.3	[./Child Page ./Child Page]	Page ./Child Page	Page ./Child Page	OK
2.4	["./Child Page"]	Child Page	Child Page	OK
2.5	["./Child Page" Child Page]	Child Page	Child Page	OK - fixed!
2.6	["./Child Page" ./Child Page]	./Child Page	./Child Page	OK - fixed!
2.7	[wiki:./Child Page]	Page	Page	OK
2.8	[wiki:./Child Page Child Page]	Page Child Page	Page Child Page	OK
2.9	[wiki:./Child Page ./Child Page]	Page ./Child Page	Page ./Child Page	OK
2.10	[wiki:"./Child Page"]	Child Page	Child Page	OK - fixed!
2.11	[wiki:"./Child Page" Child Page]	Child Page	Child Page	OK
2.12	[wiki:"./Child Page" ./Child Page]	./Child Page	./Child Page	OK

3: ../SiblingPage

#	Wiki	Link name (False)	Link name (True)	Comment
3.1	[../SiblingPage]	SiblingPage	Sibling Page	OK - fixed!
3.2	[../SiblingPage SiblingPage]	SiblingPage	SiblingPage	OK
3.3	[../SiblingPage ../SiblingPage]	../SiblingPage	../SiblingPage	OK
3.4	["../SiblingPage"]	SiblingPage	Sibling Page	OK - fixed!
3.5	["../SiblingPage" SiblingPage]	SiblingPage	SiblingPage	OK - fixed!
3.6	["../SiblingPage" ../SiblingPage]	../SiblingPage	../SiblingPage	OK - fixed!
3.7	[wiki:../SiblingPage]	SiblingPage	Sibling Page	OK - fixed!
3.8	[wiki:../SiblingPage SiblingPage]	SiblingPage	SiblingPage	OK
3.9	[wiki:../SiblingPage ../SiblingPage]	../SiblingPage	../SiblingPage	OK
3.10	[wiki:"../SiblingPage"]	SiblingPage	Sibling Page	OK - fixed!
3.11	[wiki:"../SiblingPage" SiblingPage]	SiblingPage	SiblingPage	OK
3.12	[wiki:"../SiblingPage" ../SiblingPage]	../SiblingPage	../SiblingPage	OK

4: ../Sibling Page

#	Wiki	Link name (False)	Link name (True)	Comment
4.1	[../Sibling Page]	Page	Page	OK
4.2	[../Sibling Page Sibling Page]	Page Sibling Page	Page Sibling Page	OK
4.3	[../Sibling Page ../Sibling Page]	Page ../Sibling Page	Page ../Sibling Page	OK
4.4	["../Sibling Page"]	Sibling Page	Sibling Page	OK
4.5	["../Sibling Page" Sibling Page]	Sibling Page	Sibling Page	OK - fixed!
4.6	["../Sibling Page" ../Sibling Page]	../Sibling Page	../Sibling Page	OK - fixed!
4.7	[wiki:../Sibling Page]	Page	Page	OK
4.8	[wiki:../Sibling Page Sibling Page]	Page Sibling Page	Page Sibling Page	OK
4.9	[wiki:../Sibling Page ../Sibling Page]	Page ../Sibling Page	Page ../Sibling Page	OK
4.10	[wiki:"../Sibling Page"]	Sibling Page	Sibling Page	OK - fixed!
4.11	[wiki:"../Sibling Page" Sibling Page]	Sibling Page	Sibling Page	OK
4.12	[wiki:"../Sibling Page" ../Sibling Page]	../Sibling Page	../Sibling Page	OK

Great work!

[Remy Blank]

Thanks for testing, and for the thorough analysis! A slightly simpler patch was applied in [9541].