CamelCase vs. [[Brackets]] debate
Instead of re-re-re-inventing the wheel, I had a look at how WikiPedia does that (see MoinMoinVsMediaWiki) - and (unlike other stuff there) I don't think it is bad. It is rather nice and more complete than what moin does. Also, their URLs look pretty and they also use _ in URLs and pagenames rendered as blanks in link and title. So we maybe simply should change in that direction.
CamelCase should be configurable (is bad if you get many wrong links, like in a programmers wiki)
- #pragma disable-camelcase + cfg.allow_camelcase (same way section-numbers are done)
languages with no upper/lower case may want to use an underscore_link_pattern - should be configurable, bad for programmers wiki (alternatively, use free links or GaGa)
- moin has quite some bracketed links that could be maybe easier or more complete
["Free Links"] or [[Free Links]] (collides with macros)
[[Macro:Blahblah(blah)]] could be the macro format
would be too much for stuff like [[BR]]
GaGa to rule them all ;)) The problem with CamelCase and underscore_links is when they trigger at unwanted places. An unwanted place is where you have a link, but don't want a page. GaGa only links IFF there is an existing page. Creation of new pages by action=linkall toggle.
- just use a pattern, but only display links that exist
- exists: render style link
- doesn't exist: render style normal
Maybe the ##pragma should be like this:
- would enable both patterns that are currently discussed
- would disable all patterns
- would enable just camelcase
- would enable only underscore
If a hypothetical 'xana' link pattern was added, then a page containing this ##pragma would not be changed by that addition, which is probably a good thing.
Additionally, this could work similar to ACLs and be given a default value in the configuration as well. I also think that newly created pages should automatically be given a line that corresponds to the current setting in order to increase their portability and resistance against configuration changes. This line would be displayed in the editor of course, giving the user a chance to remove it. Maybe a comment would be good too:
##pragma link-patterns camelcase,underscore # this line enables the given link patterns. This is the current default # on this wiki. You may want to change the line to enable different link # patterns. If you remove it, the configuration will be used, this will # make the page less resilient against configuration changes.
This might better go into a template that is always used if no other template is selected (existing templates should probably be changed to include it). Another substitution would be needed though, the template would need to look like:
##pragma link-patterns @link-patterns@ # ... ...
Well. I dunno. Just brain-storming
-- JohannesBerg 2004-03-23 14:04:11
That would definitely solve the problem, but makes things more complicated. -- ThomasWaldmann 2004-03-28 12:46:40
I had some notes to attach here.
Two problems that bug me:
I don't like the [wiki:ForeignWiki/ForeignPage blah blah blah] syntax. I wish it were just [ForeignWiki:ForeignPage blah blah blah]
I don't like the inability to [LocalPage#subsection blah blah blah].
I'm fine w/ no CamelCase, though I'd miss it. [[This is fine with me.]] (being... a link to a page named "This is fine with me.")
- I like blank spaces being underscores in the URL. Really, you shouldn't, if you are sane, shouldn't have "This is a page" and "This_is_a_page" being two different pages on the same wiki. (I don't even like case sensitivity..!) But, that's just me.
-- LionKimbro 2004-03-27 22:36:28
WikiMedia's [[brackets]] are superior to traditional CamelCase for at least those reasons:
CamelCase is too implicit; it appears to be magic to beginners. It's trivially easy to explain it, but a newcomer is more likely to understand [[Brackets]] immediately (without explanation) than CamelCase, because there's a much clearer visual hint in the source.
How do you create a one-word link? Answer: ["Thusly"]. But that is another thing the user has to look up rather than understanding right away.
What happens if you type CapWordsAsUI? Answer: CapWordsAsUI. To get a link you must type CapWordsAsUi. Another slightly confusing aspect of CamelCase.
How do you turn it off - that is, what if you don't want a link? This commonly happens when you're referring to a software thing like JavaBeans. Answer: !JavaBeans. Or the previous hack: Java``Beans.
- This documented in the help, but could be better documented in the online help section at the bottom of the page
CamelCase LooksUgly and UnProfessional. It's hard to get people in an office environment (especially people older than you) to contribute to something that looks funny.
[[Brackets]] LooksUgly and UnProfessional. It's hard to get people in an office environment... . But this is just a matter of taste.
Brackets solve all five problems. Looks like a hands-down winner to me.
-- Jason Orendorff 2004-03-30 19:27:59
IMO, they solve no problem at all, of those you posed.
CamelCase is fairly easy to recognize. I'd say most people would figure it out on their own in a few minutes.
I don't see how [[...]] is different from ["..."] in that respect. Is [[...]] somehow magically more natural? Doesn't look like it.
yea, confusing, but remember that you're advocating to always use some other pattern, so it doesn't really count to give a case where CamelCase fails, and then say its bad because it fails there; If you want to disallow CamelCase then you'd have to write ["CapsWordAsUI"] anyway. You're basically saying something akin to: "we shouldn't use cars because sometimes they break down".
- The bang escaping is documented...
you don't really need to use CamelCase at all. No-one forces you to. So. dismissed as well.
-- 126.96.36.199 2004-03-31 02:48:46
[[...]] is superior to ["..."], since the first is "more wiki" (faster to type, especially on german keyboards ) -- ThomasLorenz 2004-03-31 11:26:17
188.8.131.52, I think the advantages of brackets are that: the user only has to learn one thing; it's immediately obvious; it's consistent so the user doesn't have to learn any exceptions; it works correctly in more cases; and it's prettier. Point for point,
- The whole point of a wiki is that you don't need to take a few minutes to figure it out; if you have people's attention for just a moment they can trivially contribute. If brackets are more obvious, that's a slight win.
It is different in that for brackets, the one-word case is not an exception. With CamelCase there are two cases, and the second case is rare, so it's that much harder for people to find an example when they need it.
Yes, I'm advocating to always use some other pattern, a pattern that doesn't have this problem. Using brackets, I would write [[CapWords as UI]], using the same consistent scheme that applies to everything else, and it would work correctly the first time. I wouldn't post it, see the brokenness on the page, and then have to click Edit again to fix it.
- I didn't find it documented anywhere on this wiki. With brackets the answer is so trivial it wouldn't even occur to someone to ask.
I really don't know what you're talking about here. I have to use CamelCase if I'm to contribute to this particular wiki; if I used WikiMedia-style names I'd be going completely against the grain.
How are brackets not a win? (1) It saves my time as a frequent user; (2) It makes the system more consistent and easier to use for new or infrequent users; (3) It's just plain more elegant and consistent.
I don't understand is why people would think CamelCase is better. --Jason Orendorff 2004-03-31 14:59:26
(Update-- Ah, yes. The bang escaping is in fact documented on this wiki; from the edit page, it's only three clicks away, second section, fifth paragraph. Simple!) -- Jason Orendorff 2004-03-31 15:02:07
CamelCase are great - this is the magic of the wiki. Most links are not one word, and they should not. The real problem with CamelCase is languages without capitals like Hebrew and ["free links"] solves it.
["free links"] are not a good solution - it too hard to type. How about this:
CamelCase - exists
[free link inside the wiki]
[http://www.apple.com external link] - exists
Alll these #pragma are very bad - unless you know C - regualr people do not. We don't need different links configuration for each page.
-- NirSoffer 2004-06-01 19:46:06
I find [free links like this] problematic - too many collisions with ordinary text where  are used in an innocent context. Two character tags are preferred. [[link like this]] sounds great except for the colliding-with-macros problem ... which is hard to solve. My vote goes for ["bracket-quote links"].
this ["..."] is a pain in the ass, you need 2*4 keystrokes and 2 hands on german keyboards for that. Using [[...]] (2*3 keystrokes, 1 hand) would be possible if we change macro syntax (and include a conversion tool).
GaGa also has the problem of unwanted links - just because I have a page named "fish" doesn't mean I want every occurrence of the word fish to link to that page. WikiNames are good in this sense because they make it explicit that I am referring to a "proper noun".
this is why there is a GaGaBlackList - every word on that page would not be linked, except if explicitely requested by a free link
- Part of that is just tradition and convention.
- A problem with losening the convention would be links appearing where there were no links before.
Another problem is that it is harder to choose and to remember. Currently it has to LookLikeThis. If you losen the rule, it could also !LookLikeTHIS - so it is hard to chose AND harder to remember when linking to an existing page.
We already use [url label]. There not really so much collisions, and anyone will learn after the first collision that  are reserved characters. And in the rare case that you must write a text about [words like this], which are not links - escape them like thits ![this is not a link]. We need easy to type links, without breaking other markup. this is great pain to type - I use this all the time with Hebrew moin, when there is no other way to create a link.
About CamelCase, it would be nice if we can use links like these:
- ThisIsLINK LINKItIs THISISSTUPIDButIsLink ALinkItIs ThisISNOTALINK ANDTHISAlso notALInk
We can use the same word regex we use today - but use all the characters in the word - instead of just the CamelCase part, as you see above.
There are many moin moin wikis, and breaking the markup is very bad for all our users. -- NirSoffer 2004-08-03 08:28:08
Brief comment: I agree with the statement above that CamelCase should be configurable - it can really get in the way if you use it for technical documentation and the like. Also, a note about wiki labels ("why not just use good wiki names?") - if you use subpages extensively your wiki names can get very long. For example, if you use a convention like Product/Version/Phase/Project Name/Requirements. It is excellent for keeping the wiki nicely organized but you really need labels if you want your links to be reasonable. -- MikeHollick
This is a good point, about wiki names like Product/Version/Phase/Project Name/Requirements. But if you are linking anywhere inside those pages, you can use relative links for sub pages /SubPage or parent ../ or siblings '../SiblingPage'. Outside this tree, you will have to use external links to get into the tree, like: [http://bla.com/Product/Version/Phase/Project Name/Requirements Requirements]. For these type of links, we can use this markup: wiki:"very/deep/tree of documents/here". -- NirSoffer 2004-08-04 16:31:54
External links would work, but in my opinion this is pretty awkward, and would introduce the external WWW icon before all of these links. I guess it boils down to whether the labeled wiki link feature is worth whatever additional complexities are introduced in terms of markup. My vote would very definitely be that labeled wiki links are a critical feature! Personally I don't have a problem with sticking with the current [:wiki/link:label name] format, though. -- MikeHollick 2013-06-19 16:12:53
I am much a fan of Mediawiki links. I dont know what collision problems this imposes here - seems like an excuse to not do things right to me. CC sucks rocks and thats all that can be said about it; it imposes silly non-intuitive use of capitals, depends too much on case sensitivity in a too-common context, and I think it was really just a hack, because people originally just wanted to avoid coming up with a new scheme that people might not like. It looks like everybody knows what to do: just how to do it is in question: Use the Mediawiki scheme; write a game plan for refactoring which files with what. -KS
I'll just add my $0.02. I'm trying to merge in documents from another source, and CamelCase is a major pain. Going in and putting a '!' in front of every accidental CamelCase is a total hastle. How do you grep for CamelCase? With brackets, this problem would be significantly reduced. Why? CamelCase exists in normal text, double brackets are very very rare. I'm not so extreme as to advocate the death of CamelCase, but I do like the pragma idea very much indeed. - 2008-11-17
Perhaps to help us all think this through, we should say that we are discussing the WikiName feature of MoinMoin, and avoid the use of CamelCase as its synonym. Yes, words in the CamelCase format trigger the WikiName feature, but it seems (to me anyway) that we are considering other ways (LinkPatterns) to make a WikiName.
If it's OK, may I suggest a wikiname pragma:
the settings for #pragma wikiname are: on, off, and auto
the on and auto settings may also have the using sub-setting.
on = (default) behavior as is currently the standard (WikiName feature is enabled)
off = WikiName feature is disabled
The auto setting will allow each page to have a dynamically built list of bona fide WikiNames; whenever the software recognizes a WikiName (per the current LinkPatterns allowed) between double-brackets, it adds that WikiName to this list. Thereafter, any WikiName outside of double brackets which is a member of that list is made into a link (WikiName feature selectively enabled). In practice, the author encloses a WikiName in double-brackets once (towards the start of the page), and a link is made for that WikiName wherever else it may appear afterwards in that page.
using = sub-setting of on and auto which indicates the LinkPattern to use. Available link patterns are camelcase and underscore.
#pragma wikiname off
WikiName feature disabled
#pragma wikiname on
#pragma wikiname auto
WikiName feature selectively enabled
#pragma wikiname on using camelcase underscore
WikiName feature enabled, recognizing CamelCase and Underscore LinkPatterns
#pragma wikiname on using underscore
WikiName feature enabled, recognizing only Underscore LinkPatterns.
I wonder if anyone has implemented one of the ideas mentioned at the top of this page, i.e. to render a link from WikiName only if such a page exists? Taking into consideration that there's already an option to show question mark for missing pages, I don't think that it's a big deal to add one more option. At least that's what users of my wiki are asking for, so I'm planning to make a patch if no-one did before... -- AlexanderAgibalov 2009-06-25 10:03:36
Well, here's a patch (better to make a separate option which will go here and in multiconfig.py, but no time, as usual):
in parser/text_moin_wiki.py in def _word_repl just extend an if-statement with one more condition: 612c612,613 < if abs_name == current_page: --- > checkpg=Page(self.request, abs_name) > if (abs_name == current_page) or not checkpg.exists():
-- AlexanderAgibalov 2009-06-29 09:40:49