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
On Friday, November 20, 2020 at 9:01:53 AM UTC-8 jn.pierr...@gmail.com 
wrote:

> 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...
>
>
> Le vendredi 20 novembre 2020 à 16:47:20 UTC+1, Ed Heil a écrit :
>
>> 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!
>>
>>
>> On Friday, November 20, 2020 at 5:47:11 AM UTC-5 TiddlyTweeter wrote:
>>
>>> Ciao Soren
>>>
>>> On Thursday, 19 November 2020 at 20:53:05 UTC+1 soren.b...@gmail.com 
>>> wrote:
>>>
>>>> I use WikiWords in my Zettelkasten 
>>>> <https://zettelkasten.sorenbjornstad.com>. Besides saving a couple of 
>>>> keystrokes, I actually like them aesthetically ... 
>>>
>>> And I think the restrictions in form 
>>>> <https://zettelkasten.sorenbjornstad.com/#GenerativeRestrictions> 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
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/ca43f8ef-d9e5-4e7e-aa0d-40353a4a8e10n%40googlegroups.com.

Reply via email to