CamelCase vs. [[Brackets]] debate

I think there is some need for the MoinMoin link patterns to be refactored. (!) This has been done for moin 1.6, see HelpOnLinking.

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.

Maybe the ##pragma should be like this: 

   1 ##pragma link-patterns camelcase,underscore
   2 ##pragma link-patterns
   3 ##pragma link-patterns camelcase
   4 ##pragma link-patterns underscore
  1. would enable both patterns that are currently discussed
  2. would disable all patterns
  3. would enable just camelcase
  4. 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:

Other stuff:

-- LionKimbro 2004-03-27 22:36:28

WikiMedia's [[brackets]] are superior to traditional CamelCase for at least those reasons:

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.

  1. CamelCase is fairly easy to recognize. I'd say most people would figure it out on their own in a few minutes.

  2. I don't see how [[...]] is different from ["..."] in that respect. Is [[...]] somehow magically more natural? Doesn't look like it.

  3. 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".

  4. The bang escaping is documented...

  5. you don't really need to use CamelCase at all. No-one forces you to. So. dismissed as well.

-- 217.225.31.53 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

217.225.31.53, 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,

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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:

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"].

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".

Is there any reason the WikiNames regexp can't look more like [A-Z][a-z]+([A-Z][a-z]*)* ? In other words, acronyms and single-letter words are allowed in a WikiName anywhere except the beginning?

-- DoranMoppert (2004-08-03), with some comments of -- ThomasWaldmann 2004-08-04 08:27:46

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:

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 2024-04-18 17:16:32

Mike, there is no current format like this [:wiki/link:label name] but [:this works] without label - now, like LinkPatern. -- NirSoffer 2004-08-04 18:41:08

It does seem to work - this is a link to this page... I can't remember where in the help pages I saw this but we've used it pretty extensively without problems... -- MikeHollick2024-04-18 17:16:32

It does work - but not documented on 1.1, 1.2 and 1.3 at least not on the HelpOnLinking page. Great to find this. :) -- NirSoffer 2004-08-04 21:27:32

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:

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

MoinMoin: LinkPattern (last edited 2014-02-19 14:14:33 by 37-5-232-12-dynip)