The using of CamelCases and what the Tilde is doing

#1

Hello, everyone!

The subject has certainly been discussed a hundred times - just not by me. So I just want to get rid of it at this point.

Even if CamelCases sometimes offer a helpful alternative, I avoid them mostly. For me, automatic linking has repeatedly led to undesirable effects in the past. These are not only caused by unwanted links that are superfluous in their repetition and that disrupted the flow of reading due to their constant color changes.

If I still use CamelCases every now and then for speaking names (they are ideally suited for this), then also to forego further explanations. In my wikis with automatic linking, such links often refer to a non-existent tiddler, which means that they are even emphasized in the typeface, as the font style changes as well as the color.

Of course, it is possible to work around all of these problems by adding a tilde. But this is an mental interruption by editing and leads to irritations in my flow of thoughts. While the conscious setting of brackets clearly identifies the link in WikiText as well as in my own flow of thoughts and highlights it as essential, CamelCase words remain largely inconspicuous without their color highlighting. Setting the tilde, on the other hand, draws attention to those potential connecting points that are considered less important for the further train of thought (otherwise the link would be desirable). Therefore I have decided to turn off automatic linking in several wikis.

Unfortunately, this not only leads to problems with the import of tiddlers from other wikis if automatic linking is activated for them. Such an import may be associated with work, but if the number is not too large, these tiddlers can also be adjusted by hand if necessary (add brackets and remove tildes). The real problem here are the shadow and system tiddlers! If I overwrite them, they can’t be updated automatically any more.

I don’t want to claim that it would be better to forego CamelCases as a matter of principle, or to switch them off by default. However, it would be helpful if CamelCases were noted in brackets like other links in all shadow and system tiddlers. It would also be better to suppress the tilde display always when rendering CamelCases, regardless of the setting whether CamelCase links are activated or not (which would require a change in the core, right?). I don’t see any need to show them while linking is off.

Best regards,
Johannes

#2

There was a discussion quite some time ago at GitHub, where Jeremy suggested some changes, different to the PR that was submitted. Improve global "wikilink" parser disabling by pmario · Pull Request #2844 · Jermolene/TiddlyWiki5 · GitHu

Since this would have been a different change as the PR we discussed I wasn’t able to handle it at that time. … May be it’s time to have a closer look again.

#3

Well, I see, it’s not a new idea, even Jeremy got it since 2017 or longer.

But hey, that cant be true:

Yea, that thought has come to me too. … May be CamelCase “autolinking” is just for users that started working with computers in the 80’s or earlier :wink:

I 've punched my first Pascal program in punch cards in 1979. I have to know that! :rofl:
We had to save every bit in the memory, and at the drive, so the saved spaces were a real advantage, but such an auto link function was pure laziness in the wrong place even back then.

Even if it wasn’t possible to change it in 2017, it would be nice if it comes soon. The new 5.2 would be a good reason to change that too. Unfortunately, I stopped programming in the 90s because I had other tasks. So I’m not of much help at the moment when it comes to such work. It is the same with the English language, which I have rarely used in the past 30 years. Right now, Google is my best friend on this.

#4

J C S

I support the desire to suppress the tilde if desired… but I think there are plenty of options regardless. Perhaps the introduction of a parser option that if wikilinks are turned off, it optionally suppresses the tilde. Its ignored if wikilinks are active either globally or in a specific tiddler.

  • because you need not use camel case unless you want an automatic link. With a few exceptions camel case is not normal in English at least.
  • There are other work arounds other than tilde like css change’s to how the links appear. Or using the free links plugin that you can toggle on/off in addition to turning off wikilinks in the parser
  • perhaps consider using the tiddler class field to apply an alternate formatting to wikilinks
  • links to missing tiddlers are also links to missing information, which is very important in knowledge and information management.
  • Its easy to turn this off for the whole wiki, or use a rule to turn it off for a particular tiddler, or as you mention for a specific link.
  • This feature is actually a fundamental feature of Wikis.
  • I rarely make use of camel case in prose, I use it extensively in macros and other more sophisticated tiddlers.

In a separate project with @pmario the custom wikitext plugin would allow you to design an alternative to the tilde to suppress camel case thus control it as you wish.

Regards
Tones

#5

Hi Tones, thank you for your statement. I’m happy to see that you agree that it may be an good idea to suppress the tilde.

But the rest of your statement - ok, how I shoud explain it in English words…

  • because you need not use camel case unless you want an automatic link. With a few exceptions camel case is not normal in English at least.

Yes, you are right, camel case words are not normal in English - and also not normal in any language, I think. But, for example: CamelcasE also may be an automatic link, and it follows a rule, much easier than CamelCase - but, for me, only CamelCase is a camel case. You see the difference? So, what you tell me above is, that I may not use camel case in TiddlyWiki in other case than automatic link, because you don’t see any other use for it, than an automatic link? I think, good programs are made for users, not for programers. And so they also shoud give room for thoghts, programer normaly never thoght about. Or, how I say it above: Camel case words like CamelCase are “speaking names” - a name for a thing which tell me what it is. And I think, even in English CamelCase is much easier to read and understand than Camelcase as a name for a word which is a camel case.

Or, in a small little word:
The way we think depends on the rules we groked. And we never grok all rules in one.

What I want to say in my first post is: There are good reasons to use camel case words for automatic links as same as to use them not, even if you want to use them for other purpose. So TiddlyWiki don’t should prefer this or that. It shoud be work on both in the same good way, but it doesn’t - because of the tilde and because of the way how wikified words are used in documentation and configuration tiddlers.

If I say documentation, I don’t mean big projects like the user guide, which stay for its own, but the little ones, which comes with every well formed plugin. And the using of brackets are an good and simple way to make camel case words working in both ways. But there is no similar way for the tilde, and I don’t understand why.

Of course, the brackets are superfluous in many cases, if you have activated the automatic wikification, but they do not interfere either. With the tilde it is just the other way round. You not only lost the automatic links, when you switch off the automatic (which is ok in most cases), but also the tildes interfere afterwards, and I don’t see any use in showing them.

So I don’t looking for work arounds but for an general solution for the tilde if possible, and if there is no way, I try to understand why. I don’t see any need for showing the tilde at this place, if you switch off the automatic, but it interferes, if it is shown in the rendered tiddler.

You are right, this is an important point:

  • links to missing tiddlers are also links to missing information, which is very important in knowledge and information management.

But there are other ways to get these links and they may be equal or better. Usually I use the brackets for it. And using camel case or not - you have to code it, if you want a link, but if you only use brackets for coding links you don’t have to code, if you don’t want one.

You say:

  • Its easy to turn this off for the whole wiki, or use a rule to turn it off for a particular tiddler, or as you mention for a specific link.

That’s right, but the point is, the switch doesn’t work properly, how I have explained above.

But hey, fullstop!
Are you using this switch to see, where you have insert a tilde and you are searching them, to delete? In this case I understand, why you want an own switch for the tilde, if they are generally hidden in this place.

#6

I think the discussion at GitHub made it clear. … Jeremy was OK with disabling automatic wikilinks by default if we also fix some other widgets like syslinks and extlinks.

On the other hand there are some cases where automatic wikilinking should stay to be on. eg: https://tiddlywiki.com for example. It’s common now, that valid links are “wikified”. … BUT it should be able for users to avoid that. …

So if I type ~https://tiddlywiki.com … it should not be wikified as shown here. BUT it should be shown as plain text: https://tiddlywiki.com (without being converted into code).

So the tilde prefix can be used to negate a global rule. … On the other hand, if the global rule is disabled, the tilde should be gone and the rest should be plain text.

With TiddlyWiki we have a “brand” name, which will be wikified automatically. But this can be annoying if the work comes up 10 times in a tiddler. …

For me personally I want 1 out of 2 things that should happen.

  • Either the first CamelCase link should be wikified … or
  • The last link should be wikified.

BUT only 1 of them should be wikified. … As J_C_S points out, it will be easy to do with [[TiddlyWiki]]. So I can be 100% sure, which one it is. No matter if global CamelCase is switched on.

just some thoughts.

1 Like
#7

pmario,

totally agree!

Wikifying of valid web links is a very important matter that I would not want to miss either. But for me as a user, web links and camel case links are completely different. So switch off camel case links never shoud switch off any other links.

On the other hand, the tilde is of course also an important switch. But that’s exactly what it is! The tilde is a markup from WikiText and should be just as invisible as any other markup after rendering. Nobody would show the * or the # at the beginning of the line afterwards. Same to the tilde at the beginning of an expression. It handles the expression, no more, no less.

The rule you describe for internal links is what Wikipedia also considers good style. In most cases it is sufficient. In the other cases it is usually just as important to set a link only once, and with the brackets it is possible to choose the exact link you want, which is why it is my preferred method.

#8

That’s not happening. … I think it’s extlinks.js that handles that. … BUT the functions are somewhat “intertwingled” :slight_smile:

1 Like
#9

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.

#10

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.

#11

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).

1 Like
#12

@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]]

1 Like
#13

Checked the French edition as well thinking it might handle camel case differently. It also does not trigger camel case with Jean-Pierre .

#14

@jypre I believe I found a practical work around.

See tv-wikilinks Variable

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

1 Like
#15

Thanks Tones. You’re so helpful!!!

1 Like
#16

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).

1 Like
#17

@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.

#18

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.

#19

@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.

#20

I get it. I love it. :heart:

More please.