This is what I like to see! As a developer, you have an eye on the entire project, while I as a user usually only see my small HTML file.
Mario,
This “new behaviour” needs to be optional because not suppressing the tilde is the current standard, just as someone may not want it suppressed, for all we know others may have made use of the fact it was not suppressed. All this is behind the suppression of Wiki-links which itself is only a subset of cases.
Just for information, current CamelCase is wrong because as far as I can say , my first name is not camel case but tiddlywiki thinks that “Jean-Pierre” is camel case! Really, camel case should not include anything but letters!
I switch off camel case in any wiki which I sign with my name.
Also’ the handling of ~ was not the same in the text fields and otherwise, which is not very logical (or so do I remember and it may date from tw classic era).
@jypre it must be a personal thing because I sometimes go out of my way to make my name into a link [[Tony]] because clicking this takes them to me contact info, it also appears in tiddler subtitles if $:/status/UserName is set.
I was building a solution for you when I discovered Jean-Pierre does NOT trigger camel case on Tiddlywiki.com".
However a solution for you may be as follows;
\define sig() Jean-Pierre Macron and use <<sig>>
sig=signature pick a French version.
You can change the above macro if you want to hide it or link
\define sig() [[Jean-Pierre Macron]]
Checked the French edition as well thinking it might handle camel case differently. It also does not trigger camel case with Jean-Pierre .
@jypre I believe I found a practical work around.
Try the following with and without the first line. You will see how the result is when on it suppresses all links and does not show the “~”.
\define tv-wikilinks() no
CaMmel
~CaMmel
[[CaMmel]]
\define tv-wikilinks() no
Could be inserted directly in a tiddler or made into a global macro (I tested this). It can also be overridden locally with \define tv-wikilinks() yes
Thanks Tones. You’re so helpful!!!
I got some feedback from a reader of Grok TiddlyWiki the other day which might help clear up this confusion. TiddlyWiki used to consider this CamelCase back in TWC, but it no longer does starting in 5.0.14. Wikilinks now have to be all letters, as @jypre says it should. Specifically, it now requires:
- At least one uppercase letter (
[A-Z\u00c0-\u00d6\u00d8-\u00de\u0150\u0170]
- Then at least one lowercase letter (
[a-z\u00df-\u00f6\u00f8-\u00ff\u0151\u0171]
) - Then one more uppercase letter.
- Then as many more uppercase and lowercase letters and numbers as you like (
[A-Za-z0-9\u00c0-\u00d6\u00d8-\u00de\u00df-\u00f6\u00f8-\u00ff\u0150\u0170\u0151\u0171]
).
In contrast, you can see in the TW2 parser plugin that TWC markup’s notion of all this was somewhat bizarre:
For instance, a “lowercase letter” could be a number, and ABC_-_
would be considered a CamelCase link, because it starts with two or more uppercase letters and then some “lowercase letters” (underscores and hyphens).
@sobjornstad thanks for this research. it would be great if we could customise these as a user, especially if it were applied to selected content because generating links from content is a key feature of tiddlywiki, especially the “wiki” part.
It could be used to extract “future tiddler titles” from any input text, for example one could say " anything-anything " should be a link, or even " .anything" should be a link. In code one may have defines, variable/macro references made into links, Then we have the ## links Operator which can extract all the links there in.
So one could alter or add to the link generation algorithm’s. The advantages of such links is one can click and create the corresponding tiddler as part of “data mining” but this need not be reflected in the text, extracting strings from say programing code say a function call could be done to quickly document all function calls in the code.
I suppose what I am saying is if this were hackable we would take the “hyperlinking concept” to a whole new level. Along with Custom markup (an existing project) we would hand much more power to the wiki user for documentation, analysis and more. It would surpass features in Wikimedia for example.
I have a project underway that identifies verbs, ie doing words, which imply an action and could identify todo items automatically in text. I would love to have all verbs identified in my text. Specifically given a verb eg “call” in “then call joe blow!” a link [[Call joe blow!]] would be created and treated as a todo item.
Actually this would make sense as a plugin one could generate alternate views of the same content. One that applied all the above rules and any additional ones or edits, allowing one to hide the standard view. This way @J_C_S and @jypre could configure exactly as desired on what ever tiddler condition the want without modifying the core and stuffing up imported content which may rely on the default behaviour.
Such a solution simply extends the well known concept of tiddler/wiki-links so would be very easy to use.
I can code all of this but a little weak on the regex, and applying multiple rules at the same time to incoming multi-line text.
These definitions are very low level, and all of them are used within regexp configurations that are used to render TW wikitext. Those codes are used all over the places in the core but not everywhere, where they could be used. …
The problem with regexp errors is, that they fail silently.
So if a user creates an invalid configuration, it may have side effects on the whole wiki rendering process. It may have side effects in completely different areas. …
The result is a support request similar to: “The wikitext rendering is broken”
It’s not: “I did break the wikitext rendering”
We do have many possibilities to dynamically create wikilinks in a reliable way.
IMO changing those configurations should not be one of them.
@pmario I was starting to think that as I wrote my reply.
Actually this would make sense as a plugin
What I suppose I would still suggest is the “textPrimatives” were better documented and transported to a plugin that could apply variations of them to a tiddlers text field. Thus I could dial another set of criteria/filer and if necessary regex to use other effective “parsing rules” to generate tiddler links to missing or existing tiddlers.
Its kind of a link “customisation” in contrast to the “Custom Wiki”. I am sure I can write the filters but I do not know how to turn the result into links at render, although I could list them below.
Basically opening the wikilinks algorithium up to enhancement on selected tiddlers.
I get it. I love it.
More please.
Couldn’t you bypass this problem by making a copy of those regexes used only for the purpose of identifying wikilinks? Then if there’s an error, there just wouldn’t be any wikilinks? Hopefully the problem would be obvious if you changed the wikilinks settings and wikilinks stopped working.
? Does that mean jypre is using TWC?
My assumption is that they learned on TWC that it didn’t work properly and haven’t tried it again since then. Especially because of this bit:
I’m curious is there a way to run a filter that would display all tiddlers that are CamelCase?
It would be possible if you took the TW5 Regular Expressions and built them into a test.
However I would ask Why?
And also note: although camel case can “generate a title” a title itself is not necessarily camel case, and in fact camel case is word based, so a title may or may not be a camel case word, or contain zero or more camel case words.
You might want to find them all and convert them into real links before turning off Camel case. Just a guess.
I tend not to use camel case too often, but I would be curious mainly because we have many options for filtering tiddler titles.
I searched around for a camel case regex pattern, but it seems to match tiddler titles that also contain spaces. Is there a way to exclude spaces from the match?
<$set name="camel-case-pattern" value="[A-Z]([A-Z0-9]*[a-z][a-z0-9]*[A-Z]|[a-z0-9]*[A-Z][A-Z0-9]*[a-z])[A-Za-z0-9]*">
<<list-links "[!is[system]regexp:title<camel-case-pattern>]">>
</$set>