[UPDATE] uni-link pugin V2.1.0 released

[PMario]

Hi Folks,

I just released an updated version of the "uni-link" plugin V 2.1.0

Intro-Video: Can be seen at the link above

What's New

Uni-link Search

[[case insensitive title|??]] will do a literal, case-insensitive title search. It will return the first tiddler it finds.

Examples:

[[this is a test|??]]  will link to eg: "This is a Test" ... If the tiddler exists!

Important

• uni-link V2.1.0 does not contain a "relink plugin" addOn!
• So if you change the tiddler name, those links won't be changed!

relink-support should follow soon.

The original Intro-thread is: [INTRO] uni-link V1.0.0

have fun!
mario

PS - If you like it: Support it :)

[Si]

Hi Mario,

I only just noticed your Uni-link Search feature! Very handy -  I have been frequently writing things like [[really good idea|Really Good Ideas]], so this will save me a lot of time.

I have a question however: Is there any way to customise exactly how the search is applied?

Many of my titles are in singular (in English), but I often refer to them in the plural. For example I might have a tiddler with text like this: "The library contained a lot of [[books|Book]]."

I'm wondering if there is a way to use Uni-link search, but tweak it so it will ignore the final "s"? So [[books|??]] would automatically link to [[Book]].

Anyway I was very happy to find this plugin, thanks!

[PMario]

On Sunday, June 27, 2021 at 10:58:41 PM UTC+2 Si wrote:

...

I only just noticed your Uni-link Search feature! Very handy -  I have been frequently writing things like [[really good idea|Really Good Ideas]], so this will save me a lot of time.

There is a little work around, that looks a bit strange. eg: I found some [[book|??]]s.   So the link will only cover the book text. I know that's not pretty but it creates valid sentences.

The second workflow that works immediately is: using aliases eg: The "Books" tiddler gets 2 of them "book" and "books" may be [[new books]] and so on .... Use [[book|?]] or [[books|?]] problem solved.

 

I have a question however: Is there any way to customise exactly how the search is applied?

At the moment - no. ... The function is executed directly in javascript.

 

I'm wondering if there is a way to use Uni-link search, but tweak it so it will ignore the final "s"? So [[books|??]] would automatically link to [[Book]].

The main problem is, that singular / plural rules depend on the language. book - books in German is Buch - Bücher

So a hardcoded rule won't help the plugin.

The second problem is, that it has to work in both directions. So imo a link like [[books|??]] needs to search for "book" and "books"  ... [[book|??]] has to do the same thing. ... This will make the search function 50% slower :/ 

It would be possible to implement "plural" / "singular" filter rules. But they will be language specific. Some 3rd party libraries will be needed. So there would be an additional plugin per language.

UNI-LINK alias already uses macros instead of hardcoded links. ... but at the moment link-search outputs a "link", so the built-in "backlinks" handling works. If link-search would output a macro, a new "backlinks" handling will be needed. :/  I know how to do it, but it would add extra complexity.

The re-link plugin is very popular and I try to keep uni-link compatible with it. IMO the singular / plural links will definitely be out of the scope, what re-link should handle. ...

The question is interesting and valid, and it seems to be an easy change. .. But due to its language specific nature, it isn't. Implementing it will probably double the actual complexity of the plugin.

So all in all using aliases instead of link-search will win in terms of simplicity. .. And aliases don't need language specific plugins ..

hope that helps

mario

[TiddlyTweeter]

PMario wrote:

Si wrote:

...

I only just noticed your Uni-link Search feature! Very handy -  I have been frequently writing things like [[really good idea|Really Good Ideas]], so this will save me a lot of time.

 

I'm wondering if there is a way to use Uni-link search, but tweak it so it will ignore the final "s"? So [[books|??]] would automatically link to [[Book]].

The main problem is, that singular / plural rules depend on the language. book - books in German is Buch - Bücher

So a hardcoded rule won't help the plugin.

The second problem is, that it has to work in both directions. So imo a link like [[books|??]] needs to search for "book" and "books"  ... [[book|??]] has to do the same thing. ... This will make the search function 50% slower :/ 

It would be possible to implement "plural" / "singular" filter rules. But they will be language specific. Some 3rd party libraries will be needed. So there would be an additional plugin per language.

This is a very interesting technical discussion. Why interesting? Because it illustrates the huge issue of language precision v. language latitude.

Personally I see is as a GENERIC problem, not anything specific to the excellent UNILINK.

While it is possible to emulate natural language usage (i.e. code for variations of plurals; or passive v. active voice) I'm not sure it is ever satisfying.

A related, semantic, case in point is the breeding of Topics on TW Links where we have "Theme", "Themes", & "Theming" . That makes no sense and the proliferation clogs the visuals.

The re-link plugin is very popular and I try to keep uni-link compatible with it. IMO the singular / plural links will definitely be out of the scope, what re-link should handle. ...

Right. 

The question is interesting and valid, and it seems to be an easy change. .. But due to its language specific nature, it isn't. Implementing it will probably double the actual complexity of the plugin.

Right.

It's one of those "between the devil and the deep blue sea" issues?

Just FYI, I personally deal with this kind of issue by setting "CONVENTIONS" (case, plurality) for each particular use case and never change them.

This is merely a side-comment. 

Best wishes, TT

[PMario]

On Monday, June 28, 2021 at 11:18:29 AM UTC+2 TiddlyTweeter wrote:

While it is possible to emulate natural language usage (i.e. code for variations of plurals; or passive v. active voice) I'm not sure it is ever satisfying.

That's right, because languages haven't been designed to be expressed by algorithms. They have been designed by the human brain. And it seems humans do like "exceptions" from the norm, which tend to cause problems for programs.

-m

[PMario]

There is one thing, which is also interesting. Browsers have a lot of different built in functions already. The problem is, we don't have wikitext representations for them. This is a whole new field for possible improvements ... if someone wants to collect some fame ;)

[TiddlyTweeter]

PMario wrote:

That's right, because languages haven't been designed to be expressed by algorithms. They have been designed by the human brain. And it seems humans do like "exceptions" from the norm, which tend to cause problems for programs.

Ha! Great reply!

The way I put it is this: 

  The computer works for ME! 

  I don't work for IT!  

TBH, a lot of internet sites seem to believe in the latter (i.e use algorithms to impose solutions and logic), to their detriment, rather than the former.

Just saying, TT

[Si Si]

Hi Mario, thanks for the response.

There is a little work around, that looks a bit strange. eg: I found some [[book|??]]s.   So the link will only cover the book text. I know that's not pretty but it creates valid sentences.  

Thanks, this is probably the best workaround. 

The question is interesting and valid, and it seems to be an easy change. .. But due to its language specific nature, it isn't. Implementing it will probably double the actual complexity of the plugin.  

Of course - I was not expecting there to be an easy way to build this into the plugin. I just wondered if there was an easy way to hack it.

Having said that, I did have an idea. Not sure if it makes sense or not, but I'll put it out there: You could allow users to add an optional filter expression to be applied to the search term before it is used.

For example take [[books|??]]. By default this will work as it currently does, but from a global config the user could add the filter trim:suffix[s]. This would be applied to [[books]] and then the result used as the search term. 

Although I think this would largely solve my problem, I'm not sure how useful it would be in general, but I thought I'd put it out there.

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/35_6ltCXEvs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/a68737d8-c2ab-457d-91c8-d0942d696133n%40googlegroups.com.

[PMario]

On Monday, June 28, 2021 at 5:49:48 PM UTC+2 Si wrote:

For example take [[books|??]]. By default this will work as it currently does, but from a global config the user could add the filter trim:suffix[s]. This would be applied to [[books]] and then the result used as the search term. 

The problem is, that I would need to add a generic way. It may work for your, but an other user would probably have fun to link to [[foot]] ;) ...

I AM thinking about the possibility to implement the link-search as a macro. So it would be possible for users to modify the macro. And there they can do what ever they want. .. It's their wiki ;)

But I think this won't be implemented in the near future, since it will need a new "backlink" handling function, which I need to think about.

-mario

[PMario]

I did add a github issue: https://github.com/wikilabs/plugins/issues/101 .. so it's not forgotten.
-m

[Si]

>>> I did add a github issue: https://github.com/wikilabs/plugins/issues/101 .. so it's not forgotten.

Cool, thanks!

>>> The problem is, that I would need to add a generic way. It may work for your, but an other user would probably have fun to link to [[foot]] ;) ...

I'm not sure I understand what you are saying here! Is "[[foot]]" an autocorrect error?

[PMario]

On Monday, June 28, 2021 at 9:13:16 PM UTC+2 Si wrote:

>>> The problem is, that I would need to add a generic way. It may work for your, but an other user would probably have fun to link to [[foot]] ;) ...

I'm not sure I understand what you are saying here! Is "[[foot]]" an autocorrect error?

foot -> feet ... It was just an example where a "hack" breaks down.

I was thinking about the "irregular" forms that are easy for humans but problematic for algorithms.

-m

[Si]

Ahh OK that shouldn't have confused me as much as it did...

>>> The problem is, that I would need to add a generic way. It may work for your, but an other user would probably have fun to link to [[foot]] ;) ...

IMO this isn't that much of a problem. If the filter was added by the user, they would understand the limitations of it.

[TW Tones]

Folks,

This issue, with the different forms of a word such as foot and feet when it comes to searching or linking is no doubt a problem that has occurred before. I would not be surprised if there were data sets one could import for English at least to search for equivalents. Once found a simple click could commit it to a local version of the larger dataset, such that you could remove the larger data set before publishing your wiki (or not including in the published wiki) and have the feature continue to work.

Tones

[PMario]

On Tuesday, June 29, 2021 at 3:28:05 PM UTC+2 TW Tones wrote:

... I would not be surprised if there were data sets one could import for English at least to search for equivalents.

You are right, there are javascript libraries that know how to handle singular / plural rules. The code is usually not very big. What makes up the size are the irregular rules, because they need to be hard-coded. ..

https://github.com/plurals/pluralize/blob/master/pluralize.js ... is only 1 of them and it only contains english rules. .. Just an example

-mario

[TW Tones]

Mario,

Including such a thing is beyond my skills, however I have always felt such tools including a custom dictionary, glossary would be very useful for Authors. 

I hope also to scan all non system tiddlers and extract all English words to build a word glossary and allow additional metadata for each word found such as a formal definition for use.

Using the browsers various tools can make sense, but if you use TiddlyDesktop they may not be available. One could leverage Freelinks the uni-link plugins

As usual allowing the addition of words as needed can keep the data size down. You could have a tiddlywiki for authoring content and the resultant tiddler dragged to the publishing wiki.

Regards

Tones