Hey Mario,
Some of my points are overlapped with those in another thread, as I think
this plugin attempts to solve a core problem.
In my mind, linking is one of the two major pillars of TW
(searching/filtering being the other - why I think a lot and comment a lot
about search). If I want to link to something there are three issues of
concern:
1. what I want to type
- Aliases are magical here! A tiddler with "long title of method" can
save me many keystrokes (and potential typos!) if I just type the name of
the alias.
- Critically, this is decoupled from where I want the *link to go*,
and what I want it to *render as*. I don't ever want to type "a very
long title", or if the core also supports uniqueIDs, I don't want to type
timestamps.
- Something that I think should be incorporated into the core (!!!!)
(or at least with uni-link) is the Edit-Comptext dropdown plugin
<https://snowgoon88.github.io/TW5-extendedit/>. This plugin already
lets you define custom dropdown templates, so its natural to incorporate
the filters uni-link provides.
2. where I want it to go
- If we're not just focusing on aliases for a second, this isn't as
straightforward as I initially thought - frequently I want a link to go
to
a tiddler with a specific title. Sometimes I want a link to go to a
specific tiddler, *regardless of its title. *For example, my TW is
constantly evolving as my system of knowledge is evolving - I rename
things, reorganize, etc *frequently.* If I rename a method, or
person, etc. all of my links to this tiddler no longer work (there have
been previous discussions of renaming tiddlers triggering a
search/replace). I am more interested in linking by a UNIQUE ID (for
example, created timestamp) - that way renaming a tiddler's title does
not
trigger massive changes in the rest of your tiddlers (I use version
control, so its a bit annoying when I rename one tiddler, my commit
object
contains changes to 20 other tiddlers whose links to this one tiddler
also
had to change).
- Uni-link address this issue, by introducing a (hopefully) unique
field: aliases. So now I can link to [[coolMethod|?]] regardless of the
actual title of that tiddler. This is a wonderful feature.
3. what I want to render
- TW already supports some version of this, as sometimes its
appropriate to render a tiddler's title, other times its caption. I just
want to extend this so that the user has more fine-grained control over
this.
---------------------------
If anyone is familiar with Latex (typesetting engine for scientific
papers), I can describe the desired behavior with an analogy (if not skip
this piece). In latex, we can have a *bibliography* (list of papers) in a
.bib file (something like JSON), where a paper is entered like:
@article{citationKey,
title={The Very Long Title of the Paper},
author=...
...
}
In the *actual paper*, we make citations like this: \cite{citationKey} -
short, simple, and citationKey is something we can pick. We can also, by
way of different settingsI specify once at the top of the file, change the
way these citations are rendered in the PDF (APA, MLA, etc) without having
to change anything in our text! So, in the analogy citationKey is our
aliases and specifies where I want my link to go, \cite{citationKey} is
what I type, and what format it is rendered in is what I want the link to
show up as.
---------------------------
To your other points:
- I understand your reluctance to hardcode t,c,s - but in my mind, these
are already "core" supported fields (except for subtitle, which this plugin
already introduced and supports). I think the issue of existing users
having valid links that already look like [[|?t]], [[|?c]], etc is probably
very rare. Also, as this is a plugin, its ok for this to "break" how that
works for them right now. If (and hopefully when!) this plugin gets
accepted into the core, appropriate warnings could be issues, and it could
trigger a version bump to 5.2 (as Jeremey indicated the second digit is to
indiciate small but backwards incompatible changes).
- The issue of <<x alias>> could be very interesting (and powerful), but
I could see that being left to a plugin, like Jeds GenTags plugin.
- Showing backlinks for ?t, and ?c etc doesn't strike me as immediately
necessary as these are flags that only affect rendered/display properties.
In other words, I dont think its necessary to be able to answer the
question "show me all of my aliases where I chose to display the caption".
Even if it is appropriate, we shouldn't let perfect be the enemy of good!
In other words, this might a feature that is supported later (even much
later, if at all).
- Misuse leading to performance issues - This is true about any powerful
feature! Just like transclusion! I think with some proper warnings/caveats
in the documentation, it should be enough to let people learn and
experiment.
- The more advanced it is the less likely it will be in the core - I
think this is true generally, and I understand the reason for it. I think
that uni-link, even with the extra features I mentioned above, should be a
part of the core as it addresses one of the two main pillars in a big and
useful (and backward compatible) way.
Id just like to repeat and emphasize that I am *very very grateful* to you
for your work on this plugin! I don't want to come off as an ungrateful
user that just wants more and more features that are more and more specific
to my use-case. Uni-link is the most essential plugin I use in my TW and I
want to see it grow and become a core part of TW! It directly addresses and
greatly imrpoves upon one of the main pillars of TW: linking!
Best,
Diego
On Monday, December 17, 2018 at 8:55:05 AM UTC-6, PMario wrote:
>
> Hi Diego,
>
> Thx for the reminder. ... I'm very reluctant about hardcoding ?t, ?c, ?s
> ... What if existing users have valid links that look that way. ... So it
> would be needed to make a configuration for exceptions. ...
>
> I did think about it. ... If the uni-link parser sees: [[alias|?]] it uses
> a macro call like this <<aka alias
> <https://wikilabs.github.io/editions/uni-link/#%24%3A%2Fplugins%2Fwikilabs%2Funi-link%2Faka-macros>>>
>
>
>
> The macro code for ?t, ?c and so on would look completely different. ...
>
> So what if ?t would call <<t alias>> and ?c would call <<c alias>> ... So
> it would be possible to define ?x which would call <<x alias>> I think this
> has a lot of potential, since the user could have as many alias
> representations as needed.
>
> There is some potential for mis-use and heavy performance problems, if
> misused, ... but I like the idea.
>
> What I don't like is backlinking this stuff, which will be needed. eg:
> Show me all alias links, that display with ?c ... and so on.
>
> The main problem is, that the more stuff we can do, the less likely it
> will become a "core" element.
>
> What do you think?
>
> -m
>
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/8f8300ae-ca87-48d6-ae96-6abce38da5f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
