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 ..
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.
See: https://groups.google.com/g/tiddlywiki/c/35_6ltCXEvs
On Sunday, June 27, 2021 at 10:58:41 PM UTC+2 Si wrote:
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.
At the moment - no. ... The function is executed directly in javascript.
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 ..
On Monday, June 28, 2021 at 5:49:48 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 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.