CamelCase with slashes

[Clemens Feige]

Hello.

What is the intention of accepting slashes "/" to form CamelCase
hyper-links?
In other words why is "Camel/Case" accepted as link?
(I know it is to "allow hierarchy" but read on ...)

In routine work it happens quite often that unintended (dead) hyperlinks
are created when writing unintended texts fragments "in Berlin/Germany"
or "Tom/Lisa said".

I believe to have understood well how CamelCase works in TRAC. I also
know the documentation about it on
http://trac.edgewall.org/wiki/CamelCase
http://trac.edgewall.org/wiki/WikiPageNames

I do not really have a big problem here, since:
- one can simple insert spaces or
- escape the link with an exclamation mark e.g. "!Camel/Case" or
- use one of the proposed configuration options.

However I would like to understand what is the benefit of allowing the
slash inside CamelCase? I know that it can be used to "represent a
hierarchy". But I am not fully happy with this.

In my opinion it should be like this:
"LocationGermany/Berlin" -> shall be linked)
"Germany/Berlin" -> shall be not be linked,
because the latter can occur in natural writing and natural writing
shall not be interpreted.

Clemens

P.S.
There is also an old disscussion in #733 (especially comment 3):
http://trac.edgewall.org/ticket/733#comment:3

[Remy Blank]

Clemens Feige wrote:
> In my opinion it should be like this:
> "LocationGermany/Berlin" -> shall be linked)
> "Germany/Berlin" -> shall be not be linked,
> because the latter can occur in natural writing and natural writing
> shall not be interpreted.

I think that's totally reasonable. And since this was the behavior in
0.9 according to #733, we must have introduced a bug some time between
0.10 and now.

Feel free to open a ticket for this, and even better would be to include
a patch that fixes the corresponding regexp.

-- Remy

[Clemens Feige]

> Clemens Feige wrote:
>> In my opinion it should be like this:
>> "LocationGermany/Berlin" -> shall be linked)
>> "Germany/Berlin" -> shall be not be linked,
>> because the latter can occur in natural writing and natural writing
>> shall not be interpreted.

> From: Remy Blank> Date: 08.11.2013 20:00
>
> I think that's totally reasonable. And since this was the behavior in
> 0.9 according to #733, we must have introduced a bug some time between
> 0.10 and now.
>
> Feel free to open a ticket for this, and even better would be to include
> a patch that fixes the corresponding regexp.
>
> -- Remy
>

Hello Remy.

Thanks for reassurance. I filed a new TRAC ticket #11359:
http://trac.edgewall.org/ticket/11359

Regarding a possible patch, I fear to lack sufficient python knowledge,
although I have some experience with Regex. In which source file could
one find the Regex responsible for CamelCase detection?

Best regards
Clemens

[Remy Blank]

Clemens Feige wrote:
> Regarding a possible patch, I fear to lack sufficient python knowledge,
> although I have some experience with Regex. In which source file could
> one find the Regex responsible for CamelCase detection?

I believe this is the code that handles the camelcase parsing:

http://trac.edgewall.org/browser/branches/1.0-stable/trac/wiki/api.py?rev=11490&marks=344#L342

Looking at the annotated code, it looks like the bug you reported was
introduced in [9252], where we fixed the regexps to prevent DOSing Trac
through regexp parsing.

http://trac.edgewall.org/changeset/9252

-- Remy

[Peter Suter]

On 11.11.2013 00:59, Remy Blank wrote:
> Looking at the annotated code, it looks like the bug you reported was
> introduced in [9252], where we fixed the regexps to prevent DOSing Trac
> through regexp parsing.
>
> http://trac.edgewall.org/changeset/9252

Looks like it was actually intentional:
> WikiPageNames now also accept names like Page/Sub (which can be seen
as a good thing)

Clemens Feige wrote:
> In my opinion it should be like this:

> "Germany/Berlin" -> shall be not be linked,

I'm not so sure it's a good idea to change this back. Trac users since
0.12 have surely intentionally created such pages and links.

E.g. http://josm.openstreetmap.de/wiki/Maps/Germany

I would rather prefer not to break these.

-- Peter

[Remy Blank]

Peter Suter wrote:
> Looks like it was actually intentional:
> > WikiPageNames now also accept names like Page/Sub (which can be seen
> as a good thing)

Yes, I saw that. It looks to me like a justification after the fact,
possibly because it made the solution simpler. Christian might know for
sure.

-- Remy

[Clemens Feige]

> Clemens Feige wrote:
>> In my opinion it should be like this:
>> "Germany/Berlin" -> shall be not be linked,
>

> From: Peter Suter
>
> I'm not so sure it's a good idea to change this back. Trac users since
> 0.12 have surely intentionally created such pages and links.
>

Hi Peter.

Indeed, one has to balance my proposal with backward-compatibility with
those cases which depend on the regression.

However, I would claim that most users which actively use implicit
CamelCase-hyperlinking always use CamelCase wiki page names. The other
smaller group of users, which use non-CamelCase wiki page names, would
use the explicit wiki: macro anyway.

Clemens

[Christian Boos]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You're right, the primary motivation was the implementation itself,
for performance reasons IIRC.

Also, at that time I had a few pages in my Wikis using that pattern
(e.g. Mercurial/this, Mercurial/that) so the new behavior didn't seem
a too bad side effect. Since then, I also find myself wiki-escaping
such constructs a lot, so I wouldn't mind changing this now (if it
weren't for backward compatibility, of course).

- -- Christian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSgS7zAAoJENf0XkEiCfY2GnkIAJVeiiNR2Ny0Yuz73t6l+Q84
Ryic/mxS72MKQjXy0mgIUshuO94pDRGH729lNpK2KhglgvxkQGcrdZZCV5T131+6
aL2ZQRD97hOIOMsnfF6wT1z8BdYVhFvNO92mO8hnp8+hPschbZKDpIuGV7ADV4ug
js4A/M4G0Nc0cLGG5yBnBgZ1UqDPy/bK2k4XETNwhl5y5FdTBtTXKmw7XRF7dyzg
7eyVwsHbAPICHd2sb8ZCG9skojN2jqSpxB4fzFhUsKBELEaEiRZjI0bHtVynk3Xx
4HF4igtqz5AtcJ67ijSZsYh8KStioL27nrN6ub+qvTbHnYjHmYjoRw9DdmZtBdk=
=t5u6
-----END PGP SIGNATURE-----