Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Camel Casing Discussion

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] Camel Casing Discussion
  • Date: Mon, 9 Feb 2009 13:44:54 -0600

On Feb 09, Remko van der Vossen [wich AT stack.nl] wrote:
> > Recently I've been moving pages to add a hierarchy for organization.
> > When I move them, I also have been converting to camel casing,
> > although it hasn't been decided upon or discussed with. The MoinMoin
> > Wiki syntax automatically converts camel casing to links to the wiki
> > which is nice. In the past this wasn't possible and it was preferable
> > to have page names with spaces or underscores in them.
>
> Personally I hate camelcasing, it looks like... well a camel, it doesn't
> make much sense and it opens the way for much ambiguity. But really in the
> grander scheme of things, I think it's more a matter of what works for
> you. If the tome team can agree on one scheme and be consistent with that
> I think all of us will be happy. So while the rest of this mail may sound
> a bit negative, its merely meant to raise awareness about possible issues
> you may not have thought of. Perhaps they are non-issues, I'm just raising
> flags, feel free to take them down.

I hate it as well but when it's what the software wants to use it's not
worth reinventing the wheelto me. The fact we can configure some things
for how these links are displayed is a bonus.

Lots of good questions raised below though about things that need to be
considered, particularly for names that already have non-standard casing
and underscores.

> > It is also possible by user settings to automatically add a space in
> > between the lowercase and capital letter to provide a nice title if
> > wanted.
>
> What happens if you want a page "XML Usage"? Would we call it XMLUsage,
> XmlUsage, XML_Usage, something else? And what would happen with the above
> mentioned setting? Would XMLUsage result in XML Usage, or X M L Usage,
> something else even? What happens with names beginning with lowercase,
> uppercase, lowercase like iPod, eCos or eDirectory? What happens with
> names beginning with two capitals, like RTos?
>
> What happens when underscores are part of names, like our spell files
> PRE_BUILD, etc.
>
> > Benefits of converting to camel casing:
> > - Auto linkage
>
> I actually don't think this is that much of an advantage, when you want
> something to be a link how difficult is it just to add a couple of
> brackets. Usually I find automatic systems like these result in more work
> in trying to overcome them when you actually do not want certain behaviour
> than they save you in work when you do want the behaviour. Also when a
> page is explaining something, say the use of sorcery, it would be
> incredibly annoying if each and every mention of sorcery would get linked
> to another page. Normally you would only want the first mention linked.
> What steps does this mechanism take to avoid link diarrhea?
>
> > - Customizable
> >
> > Cons of converting:
> > - Many pages would have to be moved/renamed, and this results in
> > commit spam
>
> If it can be limited to a set time frame I don't think that would be too
> much of a problem. I think the benefit of beter structured documentation
> would outweigh a bit of commit spam.

We can theoretically do name changes like this from the shell, too, which
would eliminate the spam and be a nice test of just how well moinmoin
handles shell changes.

> > Also, this should lead into a discussion on what other characters
> > should be used when. For example, an underscore and a two-letter
> > country code could be used to denote a page translation, e.g.
> > ExamplePage_Es for Spanish.
>
> Would a namespace not be better for this? Is there perhaps functionality
> provided in moinmoin to provide multiversioned content?

Attachment: pgp9zRGla7rAJ.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page