TiddlyWiki / TiddlyWiki5

A self-contained JavaScript wiki for the browser, Node.js, AWS Lambda etc.
https://tiddlywiki.com/
Other
7.97k stars 1.18k forks source link

Thoughts about disabled CamelCase linking and the TW UI ~ prefixed text #7532

Closed pmario closed 1 year ago

pmario commented 1 year ago

I just thought about to create a PR which removes all the ~ signs from all core .multids tiddlers. ... There are 308 of them in the whole core.

But some auto camel case links cause real problems in buttons if they are active.

So for the time being I think we cannot remove them in the .multids tiddlers, because if a user activates CamelCase linking for there wiki, the "core" links will cause problems. ...

just a thought

pmario commented 1 year ago

Should we make the CamelCase linking a plugin?

Jermolene commented 1 year ago

I just thought about to create a PR which removes all the ~ signs from all core .multids tiddlers. ...

I don't think that's necessary. Bear in mind that as well as turning off camelcase linking, #7513 also adds a new parser rule for the tilde processing. It's also worth noticing that not all the tilde characters in the core/language folder are actually in .multids files, some of them are in .tid files.

There are 308 of them in the whole core.

I can't match that figure. Searching for ~ in core/language yields 24 results, searching in core yields 209 results, most of which are irrelevant.

But some auto camel case links cause real problems in buttons if they are active.

Yes, the confusion that arises is one of the motivations for turning off camel case linking by default.

So for the time being I think we cannot remove them in the .multids tiddlers, because if a user activates CamelCase linking for there wiki, the "core" links will cause problems. ...

just a thought

I think you're saying that we cannot remove the tildes from the core, which is also my conclusion. I don't think there is an issue here.

pmario commented 1 year ago

I think you're saying that we cannot remove the tildes from the core, which is also my conclusion. I don't think there is an issue here.

You are right. That's what I wanted to say ... for the core.

But I think it's a different thing for tiddlywik-com branch and the TW docs. .. There are a lot of eg: ~TiddlyWiki but some of them actually should create links. So with the new defaults they have to be [[TiddlyWiki]] ... There are several other CamelCase links that are effected.

I know that atm tiddlywiki.com has CamelCase switched on by default. .. But my question is, should it be kept that way.

I think no, because most of our users "copy / paste" content from tiddlywiki.com into their own wikis. But empty.html now starts with CameCase links disabled.

What do you think about the TW docs?

Jermolene commented 1 year ago

I know that atm tiddlywiki.com has CamelCase switched on by default. .. But my question is, should it be kept that way.

I think no, because most of our users "copy / paste" content from tiddlywiki.com into their own wikis. But empty.html now starts with CameCase links disabled.

What do you think about the TW docs?

That is indeed the key question.

I think that it would be a lot of work before we were able to turn off camelcase for editions/dev and editions/tw5.com.

I think there are only a very small number of situations where copying and pasting between the docs and a wiki with camelcase disabled will lead to unexpected results.

pmario commented 1 year ago

------- Just some numbers ------

I did search the ./TiddlyWiki5/editions/tw5.com path with the following regExp \b[A-Z][a-z0-9]+?[A-Z][a-z0-9]*\b which is just an approximation, with VSCode and

it found ~7000 matches in ~1100 files. Most of them are in tiddler titles, so I think about 80% are not relevant. .. But it is still interesting where we actually did use CamelCase words in the docs ... Many (~1300) single words are TiddlyWiki which is expected.

image

So in conclusion it seems to be a "non issue", which makes me feel better ;)

pmario commented 1 year ago

Reading my own post again. I think I'm good. So closing this issue.