Please respect the user's capitalization about mycorrhiza HOT 8 OPEN

By the way, another approach would be to store it in a separate file, next to the content file. That'd fit nicely into my imaginary storage mechanism I'm thinking about, and it'd be unambiguous, too (no need for "the same words" condition).

Regardless of which route to follow, it's unclear what title we should show in the breadcrumbs bar. Showing the user-supplied title would make it harder to know the actual hypha (page) path; if you were to link the hypha using the user-supplied title, the link wouldn't work (the title is just a cosmetic thing). Allowing to link using both variants would create a mess of ambiguity (what link is valid? why both links are valid?). Showing breadcrumbs, for example, under or above the user-supplied title would resolve the issue, but requires a bit more thought to come to a good design decision.

Using the title just for customizing the capitalization alone is not worth the efforts to implement it, IMO. Maybe we should do it like MediaWiki: replace spaces with underscores for simple titles (like we're doing it right now) and actually respect the capitalization, ignoring the case when we need to read/update the hypha or to check for uniqueness.

from mycorrhiza.

So actually, we need to keep canonical names for filesystem, but keep user-capitalized displayed names...

How about a separate file-based map which matches canonical names with displayed, and use it inside of displayed name generation? Though, it would become a big disaster as it gets out of control and becomes a mess with emojis and misleading titles... Also, path construction... Oof.

from mycorrhiza.

Yes, this is intended behaviour.

Wikis have a long history of breaking words. Starting with WikiWikiWeb forcing WikiWords on everything (see the name of http://wiki.c2.com/?XhtmlIsDead), continuing with MediaWiki not allowing initial lower-case letters by default (see https://www.mediawiki.org/wiki/Manual:Page_title), and now Mycorrhiza title-casing everything. One may call it the Wiki way.

Note that you can link [[KAS]], [[kas]] and [[Kas]] all the same, as well as [[kAs]], [[kAS]], etc. I guess it will be fine if you refer to yourself as [[KAS]] everywhere.

We have plans of allowing user capitalisation one day, but it is not going to happen in the nearest release (unless someone suddenly implements it). If you have any ideas of how it should work, I invite you to do so.

Here's my take.

If a first-level heading is the first block in a hypha and it seems to express the same words as the hypha name, its contents are used as the display form of the hypha.

For example, if we have hypha kas and this is the first line:

# KAS

It will be displayed as KAS everywhere in the UI.

There were other ideas such as setting the capitalisation in some meta block (meta { name KAS }) or having a special page for doing so.

from mycorrhiza.

Note that you can link [[KAS]], [[kas]] and [[Kas]] all the same, as well as [[kAs]], [[kAS]], etc.

Yes, I was thrilled when I discovered that, as most other wikis fail here. That's what I meant with “casefolding” in my original post.

It is true that if I link [[KAS]] it will show up as “KAS” in the text. But in the “Sibling hyphæ” column it will show up as “Kas”. I guess that's what prompted me to open this issue in the first place.

But reading your comment I can also see that if a word is, say, both a name and a noun, and there will be no way for the wiki to know how to display the page name in the “Sibling hyphæ” column, and “name” will be as bad as “Noun”.

It would be great to be able to edit the meta data, but that's not a pressing matter for me.

Thanks.

from mycorrhiza.

Maybe we should do it like MediaWiki: replace spaces with underscores for simple titles (like we're doing it right now) and actually respect the capitalization, ignoring the case when we need to read/update the hypha or to check for uniqueness.

Actually it's about reinventing case insensitivity for identifiers, like in Windows filesystems. Problems are little but:

• case insensitive filesystem lookups are resource-heavy, because it's now about scanning instead of straightforward picking (we can cache the name map, though), and also,
• unicode.ToLower, every bloody time
• subhyphae lookup, though we can just forcefully lowercase folder names, and make cache lookups for breadcrumbs... but still,
• links would accept any case, ignoring the intended capitalization, though Myco can automatically lookup and insert the proper hypha name instead (which zealously asks for caching)
• need for 'carpet rename' migration

It doesn't sound like something bad and bloated, but it really needs a name cache to make it all work as lean as intended. And, last but not least, will it meet the ideology?

from mycorrhiza.

I've already forgotten what I was thinking about back then. As far as I know, Mycorrhiza just lowercases everything before passing it down the logic layer, so it doesn't have any problems with case-insensitivity because everything is in lower case. So yeah, your points are valid. I haven't checked how MediaWiki does that under the hood, but a quick test shows that it's not actually case-insensitive:

• https://en.wikipedia.org/wiki/directsound redirects to https://en.wikipedia.org/wiki/Directsound because of some redirection code
• the latter redirects to https://en.wikipedia.org/wiki/DirectSound because of an actual redirect entry stored in the database
• but https://en.wikipedia.org/wiki/dirEctsound is 404

Titles on Wikipedia are case sensitive except for the first character; please check alternative capitalizations and consider adding a redirect here to the correct title.

Dunno how many problems it'd cause, and I'm sure @bouncepaw will come and make some real strong claims about why that approach is so bad, so that wouldn't meet the ideology either. IMO, it makes sense to leave it as it is, a display name would only cause confusion. Storing the thing right in the content file is probably messy?.. again, I don't have a strong opinion on that.

from mycorrhiza.

I'm not against the idea of having configurable capitalisation. I'm against the idea of case-sensitivity though.

MediaWiki capitalisation logic is fun.

from mycorrhiza.

I agree. I didn't think it through before I posted the issue.

from mycorrhiza.