WikiWords vs Double Brackets

298 views
Skip to first unread message

Ed Heil

unread,
Nov 18, 2020, 2:05:34 PM11/18/20
to TiddlyWiki
As a relatively new tiddlywiki user, I'm always interested in the opinions of people who have been TiddlyWiki'ing for a long time, and this topic came to mind.

When I first started using TW (earlier this year), I tended to use WikiWords for titles.  I've since gone almost entirely to double brackets (meaning titles may be single words or may have spaces in them).  When you start using titles as tags, and use things like Table-Of-Contents plugins, it seems like an obvious move to remove the "multiple words, no spaces" restriction from titles.

I'm curious though if any experienced tiddlywikists still use WikiWords, and if so what they find valuable about them.


TW Tones

unread,
Nov 18, 2020, 6:13:34 PM11/18/20
to TiddlyWiki
Ed,

Could you give some examples of your titles?
  • My suspicions is you have a misconception on titles (stand to be corrected).
As soon as you start to use tags and tiddler titles containing spaces some of the wikitext may need improvement to cater for this. However once practiced you will write your wikitext to support this from the get go. When handling one or more titles (inc tags) with spaces another method needs to be used to delineate the different titles. Given fieldnames do not permit spaces in their names you do not need to cater for them in fieldnames, but you do in their values.

If handling lists of titles, as tags is a special case (tag operators), you need to use enlist and listops operators to maintain a valid list of titles. 

Regards
Tones

Charlie Veniot

unread,
Nov 18, 2020, 8:08:50 PM11/18/20
to TiddlyWiki
G'day Ed,

I have never been a fan of WikiWords for topic (tiddler/page) creation and linking in any kind of wiki product.  I always prefer double-brackets for that kind of thing.

The preference for one or the other, I imagine, is highly subjective.  Regardless, I really look forward to hearing about pro's and con's of each, particularly from folk who favour WikiWords.  That would be pretty cool.

Cheers !

Ed Heil

unread,
Nov 19, 2020, 9:13:56 AM11/19/20
to TiddlyWiki
Hi Tones,

I'm not trying to solve any problems, it was just a matter of curiosity.  I used to use TitlesLikeThis a lot because they were used in some examples in the Tiddlywiki documentation; however, WikiWords have some limitations (WikiWords means your titles can't have spaces and can't be single words) so I don't really do that anymore.  I just use regular titles and [[Double Brackets]].  From what I've seen, that's pretty normal -- I don't see many WikiWords in other people's tiddlywikis.

And it would be kind of weird looking at (e.g.) a table of contents, and seeing a bunch of WikiWords rather than regular text.  And tagging, it would look a little weird if instead of tagging something "Bookmarks" you had to tag it "BookMarks".

So when I look at one of my first wikis and I see pages like JohnSmith instead of [[John Smith]] I think "huh, that's right, I used to use WIkiWords a lot and stopped.  I wonder if there are any people who really dig WikiWords and still use them?  If so I wonder what their reason for doing so is?"

Maybe there aren't any, maybe everybody ends up moving to non-wiki-words titles like I did!  But I thought I'd ask.

Charlie Veniot

unread,
Nov 19, 2020, 11:26:25 AM11/19/20
to TiddlyWiki
G'day Ed and all,

I've been chewing on it a bit, trying to put on a WikiWords advocate hat (which isn't fitting this cranium all that well...)

"Wiki" means, from many things I've read, "quick" in Hawaiian.  (It would be pretty cool to get some fun context/history/examples about the word from a Hawaiian!)

From my perspective, the only advantage of WikiWords is to shave off time entering the double brackets and spaces between words.  So all about squeezing max efficiency (and reducing typing-induced tendinitis o' the finger knuckles.)  Try as I might, I just can't see any other benefit.

Maybe, aside from speed for users, it was/is also a quick and easy way to implement page linking in wikis?  (It would be pretty cool to have some wiki historians chime in!) 

On Wednesday, November 18, 2020 at 3:05:34 PM UTC-4 Ed Heil wrote:

odin...@gmail.com

unread,
Nov 19, 2020, 12:00:23 PM11/19/20
to TiddlyWiki
Hi!

I used double brackets from the start. I use TiddlyWiki mainly for note-keeping and so my titles tend to be questions or statements. I also often use the [[This statement is a long title|statement]] syntax often to integrate links in running sentences. 

I think the main benefit I could see for WikiWords, is that there is an option that automatically makes links from them. But that could also be an annoyance when it creates unwanted links.

Op donderdag 19 november 2020 om 17:26:25 UTC+1 schreef Charlie Veniot:

Hans Wobbe

unread,
Nov 19, 2020, 2:17:34 PM11/19/20
to TiddlyWiki
From the (historical) perspective this links to one entry point to TheOriginalWiki.  WardCunningham is a fine example of the "minimalist" style of programming and CamelCase was a relatively simple way of automatically generating links to the 30k+ pages that evolved there.  It's been locked down for quite a while now but it is quite useful as a reference for those of us that still retain some knowledge of its content.

Enjoy.

Hans

soren.b...@gmail.com

unread,
Nov 19, 2020, 2:53:05 PM11/19/20
to TiddlyWiki
I use WikiWords in my Zettelkasten. Besides saving a couple of keystrokes, I actually like them aesthetically -- maybe because I'm a programmer, or just because I'm weird. And I think the restrictions in form help me come up with concise names for things.

That said, I think it depends a lot on your application. I think my Zettelkasten just about hits the sweet spot for WikiWords:
  • Pages usually describe things or specific ideas, so concise nouns or phrases are usually the titles
  • Extensive wiki I spend a lot of time in, so getting used to a more complicated naming convention is not an issue
  • Mostly personal -- any utility it has to other people is accidental
I would use titles with spaces if I were formally publishing something with TiddlyWiki, or sharing a wiki with others.

Ed mentioned the weirdness of having to write names like "BookMarks." It's not just a little weird, it also means you're a lot more likely to accidentally create a duplicate tiddler by adding the capitals a different way the next time (IIRC, Wikipedia started out with WikiWords titles at the very beginning, and this was one of the main reasons they nixed it). So if something doesn't naturally contain multiple words, I don't try to force the issue and just use the brackets when I need to.

I think Tones was alluding to the fact that you don't necessarily have to use the titles for display if they don't look pretty. You can always use the double-bracket form and enter a different link text than the name (e.g., [[MyTiddler|a description of what this tiddler is]]). If it's defined, the caption field on tiddlers is used by most of the table-of-contents features and a great number of other places in TiddlyWiki, in place of the title. I use the caption field pretty extensively in the customizations I make too. For instance, for book titles, I come up with a short slug with the most important couple of words and the year of publication and use that as the title, but then in caption I fill in the complete title and subtitle, and that's what shows up in the infobox at the top of the tiddler and in collected bibliographies. (Here's a good example.)

Even a bit more on this over in the informational notes in my Zettelkasten itself.

TiddlyTweeter

unread,
Nov 20, 2020, 5:29:15 AM11/20/20
to TiddlyWiki
Hans

Good, direct point.


On Thursday, 19 November 2020 at 20:17:34 UTC+1 hww...@gmail.com wrote:
From the (historical) perspective this links to one entry point to TheOriginalWiki.  WardCunningham is a fine example of the "minimalist" style of programming and CamelCase was a relatively simple way of automatically generating links to the 30k+ pages that evolved there.  It's been locked down for quite a while now but it is quite useful as a reference for those of us that still retain some knowledge of its content.

 Right. The Cunningham point was "automation of linking." CamelCase still is relevant in TW WHEN it can match a use case on naming well. Spaced naming is likely more used, but CamelCase is still highly efficient in that, in text body, it CREATES a link, even when its target does not yet exist. Clicking on it creates the linked Tiddler if it does not exist. THAT behavior makes for very efficient writing.

If you don't use that feature TW config lets you turn off its behaviour. 

TT

TiddlyTweeter

unread,
Nov 20, 2020, 5:47:11 AM11/20/20
to TiddlyWiki
Ciao Soren

On Thursday, 19 November 2020 at 20:53:05 UTC+1 soren.b...@gmail.com wrote:
I use WikiWords in my Zettelkasten. Besides saving a couple of keystrokes, I actually like them aesthetically ... 
And I think the restrictions in form help me come up with concise names for things.

Right. I agree. Constraints can be highly productive of good use--when they match well the users cognitive process.
CamelCase is particularly interesting in that its Semantics & Form co-incide. There is no need to add additional [[bracket]] construction forms that envelope.
In that sense CamelCase is: efficient,  meaningful, pretty obvious, readable & MarkupMinimal.

Of course, usage hangs out on more than that. Often CamelCase is not appropriate, requires too much forethought, won't work for titles etc.

But it still has real uses & excellent efficiency in some many use cases.

Best wishes
TT

Ed Heil

unread,
Nov 20, 2020, 10:47:20 AM11/20/20
to TiddlyWiki
Hey, thanks, all, this is exactly the kind of discussion I was hoping to hear!  It's been very informative, and I've really enjoyed looking at, e.g., Soren's Zettelkasten!

Jean-Pierre Rivière

unread,
Nov 20, 2020, 12:01:53 PM11/20/20
to TiddlyWiki
CamelCase is fine, but when you have an acronym in your title, the question of how to do starts.

for instance: HistoryOfHTMLBrowser or HistoryOfHtmlBrowser ? The first one is more consistant but so many uppercase in a row does not seem very Camel-like to me. And the second is nice but has no justification but ease of reading (but that's a very good reason indeed).

You have also some problem with apostrophes, although English has few of them, French has many. For instance "l'heure et l'habitude" would be LHeureEtLHabitude and that's ugly. You could resolve it by a title like HeureEtHabitude but this example really show that, as has been told, CamelCase is not fit for every purpose, and you have to have an extensive naming convention to avoid misspelling.

Also, orthographic corrector are showing a lot of ill-advised red because of every camelcase word and you will have a harsh time spotting the true errors or would have to clutter your dictionary with all your camels...

tony

unread,
Nov 20, 2020, 8:50:35 PM11/20/20
to TiddlyWiki
i am a fan of the c2WikiConvention (<-- note the HungarianNotation mistake! or dialect?)  of CamelCase and it has stuck over the years. i think of WikiEntries as kind of a SubjectToken, a unique semantic entity  and it is easy to create and search with other tools like autocomplete in vim and ripgrep. Prefixing the WikiEntry with AnotherWikiEntry serves as a NameSpace; a compounding that reminds me of German or Urls. My TiddlyWiki has TiddlywikiStuff and i have no problem with not CamelCasing the NextWord when compounded as my searches are often CaseInsensitive.  i agree with the issues of NamingConventions and PunctuationAsProblem when CamelCasing but since my wiki is personal, the WikiLanguage stays subjective and unique. This is important to my setup as the TiddlywikiNodeJs TidFiles are housed in a VimWiki where the VimDictionary built from WikiEntries serves as an index to afford global autocompletion much like TiddlyWiki CtrlL CreateWikitextLink; PureLazyConvenience! WikiLanguage, a fun, jumbled mess.

Best,
tony

Ed Heil

unread,
Nov 20, 2020, 10:06:02 PM11/20/20
to TiddlyWiki
Now that you mention the issues that come up with French, I guess it brings up the fact that many languages (many scripts) don't have a case distinction!  So there are definite limits to the internationality of CamelCase.

Jean-Pierre Rivière

unread,
Nov 21, 2020, 6:54:40 AM11/21/20
to TiddlyWiki
Foreign language are full of surprise! And some don't even have letters, too. CamelCasing Chinese, anyone?

TiddlyTweeter

unread,
Nov 21, 2020, 7:42:08 AM11/21/20
to TiddlyWiki
> Foreign language are full of surprise! And some don't even have letters, too. CamelCasing Chinese, anyone?  

Right. Languages differ. Pictographic languages are pretty redolent: https://en.wikipedia.org/wiki/List_of_writing_systems.

But that can't be a criticism to basic Latinate language strategies formed in early HTML though. Sure, the world would be different if Chinese or Adinkra had invented the web. Maybe, to our loss, they didn't. 

My point --- CamelCase is A case use. One with utility still. Basically, it is a cognitive & practical strategy with limited remit with a lot of merit---so long as its NOT the only way.

Best wishes
TT

TiddlyTweeter

unread,
Nov 21, 2020, 7:56:35 AM11/21/20
to TiddlyWiki
Ciao Ed

Ed Heil wrote:
Now that you mention the issues that come up with French, I guess it brings up the fact that many languages (many scripts) don't have a case distinction!  So there are definite limits to the internationality of CamelCase.

Right. That goes for most everything to do with "tech-as-text" though. It is not a TW issue per se. NOR is it an issue to do with CamelCase per.se.

Rather, it illustrates the complexities of how human meaning is represented & reproduced. And that the underlying tech emerged mostly expressed in unaccented Latinate characters. There emerged a zillion extensions in OS to deal with that, but there is no denying that the first level up from machine code is distinctly:  Unaccented European A-Z.

The French problem cases also exist in English BTW :-), though to a lesser degree.

Best wishes
TT

David Gifford

unread,
Nov 21, 2020, 8:38:46 AM11/21/20
to TiddlyWiki
Double brackets all the way. One of the first things I do when creating a new file is turn off camelcase words. And with the autocomplete plugin you don't even need to type the end brackets ]].

On Wednesday, November 18, 2020 at 1:05:34 PM UTC-6 Ed Heil wrote:

si

unread,
Nov 21, 2020, 6:57:21 PM11/21/20
to TiddlyWiki
I have pretty much always used double brackets, but it is interesting to hear about the possible advantages of WikiWords.

I tend to think of tiddler titles as a kind of compression of the information in a tiddler - a way to chunk the information into a single unit so that it can be easily combined with other concepts in my head. I should be able to look at the tiddler title and immediately have a sense of the idea that it refers to.

Maybe WikiWords will actually assist in this regard? As @soren points out, they can force you to be concise in naming things. And maybe squishing everything into one "word" would encourage you to think of the tiddler as more of a single unit, in line with the zettelkasten approach.

I think I will try switching to WikiWords for a bit and see if I notice any advantages.

Thomas Stone

unread,
Nov 22, 2020, 1:18:36 AM11/22/20
to TiddlyWiki
Is there a way to change TW's ViewTemplate to auto-expand WikiWords when in creates the link? So you would type WikiWords in the code, but the generated HTML would be _Wiki Words_ as a blue link showing the implied spaces. The link would still go to the correct WikiWords tiddler.

TW Tones

unread,
Nov 23, 2020, 12:56:15 AM11/23/20
to TiddlyWiki
Ed Et Al

Interesting conversation.

A few of my own reflections
  • When typing ideas using camel case to represent a compound idea with further details to be provided in the link, is a nice short hand, especially when I plan to expand on it.
  • Before I create a new tiddler I may edit the camel case word into a [[full link]], but until then it (Camel case) is auto-highlighted. Or I may add some spaces and make it no longer a camel.
  • If not for publishing, just organising and quick relationship development it is great. 
  • Variables and macros which are not for public consumption but define the workings is also useful
  • No leading capital such as currentTiddler is also a way to compound ideas and link two words as is camel case, it says something about the content. ie since we use currentTiddler, you will also find storyTiddler currentTab and other variables (but this is not camel case)
  • For example I would not use BookMarks but I may use W3CBookmarks to qualify it and perhaps make it a tag
  • With the relink plugin its easy to rename a tiddler that was camel case into a sentence, when you are happy converting it to readable text, and for tag names.
    • People often put the full text in a tiddler and transclude it, this with this  method {{FullExplanationTransclusion}} camel case is easier.
    • If you use the titles as sentences and text themselves camelcase is not as important (try it - its fun) , because the name is the content and the content the name.
  • Using camel case can be a way to differentiate when naming tiddlers or tags when coding 
  • Remember the EditorToolbar option to wrap the selection in [[ ]]
  • As others have said a wiki word and its resultant tiddler is a shortcut, and pretty links [[I am pretty|IAMNotPretty]] is especially important when the tiddler is a concept, this is because you will often need other text whenever you use it, but it is easier to recall the camel case [[Concepts in TiddlyWiki|WikiConcept]] [[See Wiki Concepts|WikiConcept]]
  • It helps in searching to know when you may be looking for a tiddler rather than vanilla text "WikiC" will not find all the tiddlers beginning "Wiki C" only the camelCase versions.
Regards
Tones

On Thursday, 19 November 2020 at 06:05:34 UTC+11 Ed Heil wrote:
Reply all
Reply to author
Forward
0 new messages