Globally changing internal links to display caption text if possible?

[Stuart Amor]

Is there a way of making an internal link, such as [[Contents]] return the caption field of the Contents tiddler (if it was available) rather than title?

To give you some background, I am writing a collaborative document and section titles are starting to become length and subject to being changed or reworded.   I am therefore starting to work on a system where I am using tiddler titles as a short succinct title and the caption field as the long title.  When creating the links its a lot easier to point them to the shorter tiddler title, but it would be nice to allow the previewed text (which is read by the uninitiated) to see the current long form.

I know its possible to create a macro to do this, but I would like to do it at a base level if possible?  I have already managed to change list fields etc to show captions instead, but links seem to have alluded me 

Kind regards,

Stuart

[Mark S.]

The attached is very experimental. It changes one of the core files, so if I messed up with the code you might get a red screen of embarrassment. So absolutely make a backup not only at the start but from time to time as you work with it.

Just drag and drop the attached file into your TW. A green bar will appear indicating where to drop. Complete the dialog to import. Save. Reload to activate.

The files include a macro that when invoked like <<MyTiddler>> returns a link to "My Tiddler Caption". This macro is used by the other bit of code, which overwrites the core prettylinks code to use the macro whenever you have a "pretty link" (e.g. a link with [[...]]).  BUT, if your link includes a title inside it, then the manual title will 'win' over the caption. (e.g. [[My Inline Text|MyTiddler]] will show 'My Inline Text').

If you change your mind and don't want to continue using the caption links, then delete $:/core/modules/parsers/wikiparser/rules/prettylink.js Note that this code will  supercede the default code during an upgrade. This may be a problem if this part of the code is ever changed though I don't think it has for 4 years now.

Good luck!
Mark

[Mat]

Stuart Amor wrote:

Is there a way of making an internal link, such as [[Contents]] return the caption field of the Contents tiddler (if it was available) rather than title?

Yes. I made this for that purpose:

http://aliases.tiddlyspot.com/

it is however not perfected but the main ideas are in there. Basically, you use CSS to hide the link and instead show a pseudo :after element in its place. 

<:-) 

[Mark S.]

Hi Mat,

Very clever approach! I really need to bone up on CSS. I think in the 2016 TW meet-up Jeremy said something about CSS making fools of everybody. Certainly works that way with me ;-)

I may be mistaken, but it appears that the links are only aliased when the corresponding tiddlers are open in the story river.

I experimented adding the  tc-tiddler-frame class to the open and recent sidebar items. That invoked the alias, but of course also changed the formatting. I'm wondering if there is some other more universal class than tc-tiddler-frame that could be used?

Have fun --
Mark

[Mark S.]

Just had another thought. If you used 'caption' instead of alias, I believe that the toc menus in the sidebar would automatically use the caption field. In the long run, I think it's best if 'caption' be the field that's used to display the user-readable title.

Mark

[PMario]

On Friday, June 16, 2017 at 5:41:26 PM UTC+2, Stuart Amor wrote:

Is there a way of making an internal link, such as [[Contents]] return the caption field of the Contents tiddler (if it was available) rather than title?

To give you some background, I am writing a collaborative document and section titles are starting to become length and subject to being changed or reworded.   I am therefore starting to work on a system where I am using tiddler titles as a short succinct title and the caption field as the long title.  

Here comes the problem. ... The "caption" field is intended (in core UI) to be the "short title", to be used in tabs and so on. So that's the exact opposite of what you probably need. 

-mario

[PMario]

On Saturday, June 17, 2017 at 11:00:57 PM UTC+2, Mark S. wrote:

The files include a macro that when invoked like <<MyTiddler>> returns a link to "My Tiddler Caption". This macro is used by the other bit of code, which overwrites the core prettylinks code to use the macro whenever you have a "pretty link" (e.g. a link with [[...]]).  BUT, if your link includes a title inside it, then the manual title will 'win' over the caption. (e.g. [[My Inline Text|MyTiddler]] will show 'My Inline Text').

As I saw the attachment I wanted to argue, because of overwriting the core prettylink parser. ... BUT this is a very interesting approach. Very tricky. ... and still compatible for users that don't have the "hack".

We should think about a new field name for this particular problem. ... I'm not sure about "alias" since Jeremy has his own view about an alias implementation, which may be different.

-m

[Mark S.]

But if it only needs to be short for menus ... just use it for menus and let it be long for other things. A photo 'caption' is often long. If the intention was that the content be short, there should have been a 'short-title' field.

The 'title' field is really, and unfortunately, an id field. There needs to be a standard field for long, mutable descriptions.

Mark

[PMario]

@Stuart,
Please don't be afraid by the "techy" conversation here. You scratched in important issue, where we don't have a generic solution yet!!

 

On Sunday, June 18, 2017 at 3:20:18 PM UTC+2, Mark S. wrote:

But if it only needs to be short for menus ... just use it for menus and let it be long for other things. A photo 'caption' is often long. If the intention was that the content be short, there should have been a 'short-title' field.

The 'title' field is really, and unfortunately, an id field. There needs to be a standard field for long, mutable descriptions.

see: http://tiddlywiki.com/#TiddlerFields ... Be aware that it shows most existing fields at tiddlywiki.com the empty.html file has much less.

There is the description field. It is already used in the plugin context and it's meant to be a whole paragraph, if needed.

Having a look to the TW source, imo the best field is "subtitle". It's used exactly in the way we would need it here. eg: $:/language/Modals/Download is a tiddler name and the "subtitle: Download changes".

The usecase here is: "Giving users the info they need, without confusing them."
So for me that's exactly what the OP wants. And the field name imo makes sense too: subtitle .... What do you think?

have fun!
mario

[Stuart Amor]

Thank you for all your responses. I am not at all put off at all. I have already had to make quite a few changes for this to work. There have been a few discussions about captions and alternative (non-unique) titles before. In fact this is not the first time I have been down this route, but the fact I keep coming back to it means there must be something in it. I have come from a latex background where having short titles and long titles is commonplace. I started using caption for my long titles as this appeared to be the way the list macros promoted. Although I agree that within the sidebar caption tends to be used as the short title version, which I have had swap around to display title instead

[Mark S.]

subtitle might work. I see that its been used exactly 6 times so far. But what I liked about 'caption' was that it automatically got used in the toc macros. Perhaps the toc macros could be written to select the titles with this priority:

  caption -> subtitle -> title

Mark

[PMario]

On Sunday, June 18, 2017 at 6:34:41 PM UTC+2, Mark S. wrote:

subtitle might work. I see that its been used exactly 6 times so far. But what I liked about 'caption' was that it automatically got used in the toc macros. Perhaps the toc macros could be written to select the titles with this priority:

  caption -> subtitle -> title

I played a little bit with the macro and called my version "phony". It removes the list-widget completely and would allow us to use nested transclusions to find  the first existing field. See:

\define returnText(tid) <$transclude tiddler="""$tid$""" field=subtitle><$transclude tiddler="""$tid$""" field=title/></$transclude>
\define phony(tid) <$link to="""$tid$"""><<returnText """$tid$""">></$link>

I think this should be a pretty performant solution.

-m

[Mark S.]

Oh snap -- I knew there must be some other way to make collapsing titles besides the view widget. But the text widget doesn't work and I forgot about the transclude widget.

I don't think "phony " is quite the right term. It's a bit pejorative. Maybe "prettierlinks"?

Mark

[PMario]

On Monday, June 19, 2017 at 1:35:28 AM UTC+2, Mark S. wrote:

I don't think "phony " is quite the right term. It's a bit pejorative.

 q:-) ... ok
 

Maybe "prettierlinks"?

imo to close to the original. ... What about "uni-link" in the sense of "union" or "universal" or just "one" if you want :)


I'd prefer the order: subtitle -> caption -> title   .....   because it is more backwards compatible

eg:
 - user has defined the caption field .... The TW core UI uses it to show "short" titles in tabs and the TOC
 - user installs the new plugin ... Now the prettylink-parser [[tiddlerName]] adopts the behavior of the "sidebar"
 - user installs new plugin and defines "subtitle" field .... New behavior, that overwrites existing functionality.
 - if neither the subtitle nor the caption field text fits, the user can use the existing pretty link [[tiddlerName|some other text]] function

All of the above is backwards compatible with TWs, that don't use the plugin. ...

 - if the user wants a completely different behavior, the "macro" can be changed, for a "domain-specific" version, which still preserves the "fallback" for TWs that don't use the plugin. 

Only one small feature missing: I personally would like to see a different style for the created link. So I can see, that it's not the "default" link behavior.

With a little bit of tinkering it's even possible to use tobibeer's Alias-Links macro. I'm not sure about the performance hit but it still is cool, that it's possible.

-m

[Mark S.]

The problem with Tobias' macro in this context, in addition to probable performance issues (it uses both list and regex), is that it can be broken if a person, for instance, clones a tiddler and forgets to update the alias field. At that point a linker using his macro will pick one of 2 possible sites (whichever the regex finds first) and link to it.

Mark


On Friday, June 16, 2017 at 8:41:26 AM UTC-7, Stuart Amor wrote:

[PMario]

On Monday, June 19, 2017 at 10:47:31 PM UTC+2, Mark S. wrote:

The problem with Tobias' macro in this context, in addition to probable performance issues (it uses both list and regex), is that it can be broken if a person, for instance, clones a tiddler and forgets to update the alias field. At that point a linker using his macro will pick one of 2 possible sites (whichever the regex finds first) and link to it.

Good point. ... didn't think about it.

I did play a bit more with it and did create a new parser plugin containing the "uni-link" type makro. If done that way, it can be enabled and disabled with the TW control panel. The idea at the moment is: the plugin would automatically disable "prettylink"

On the other hand, if both "prettylink" and "unilink" parser are active "prettylink" will win, since they are sorted and executed alphabetically.

What do you think? ... Relace "prettylink" or create a new one and play an "enable" / "disable" settings game.

Also @Stuart what would you prefer?
-m

[Mark S.]

Hi Mario,

I'm not sure what is being compared here. When you say 'prettylink', do you mean the native prettylink ability, the ability to force a title inline or ??

I think using your macro (renamed as unilink) with the prettlink.js script, possibly configurable (though I don't know why someone would turn it off) and rolled as a plugin would be good. 

Thanks!
Mark

[PMario]

On Tuesday, June 20, 2017 at 3:30:33 PM UTC+2, Mark S. wrote:

I'm not sure what is being compared here.

If you open "ConrolPanel: Info: Advancec: Parsing" tab, you can disable every single parsing rule.
The "prettylink" rule is one of them
 

When you say 'prettylink', do you mean the native prettylink ability, the ability to force a title inline or ??

I was talking about a new rule eg: "unilink", that detects exactly the same rule as "prettylink"  ... [[prettyLink]]
If both of them are active, prettylink will win since it the first one, that the parser uses ....
 

... (though I don't know why someone would turn it off)

We'll never know, which user / usecase may need it. ...
 

and rolled as a plugin would be good. 

OK

-m

[Stuart Amor]

I think having the option in the control panel to turn it off makes sense. Turning it off would then allow you to error check the links as the true unique title IDs would be displayed.

[PMario]

Hi Folks,

I pushed out the "uni-link" plugin: https://wikilabs.github.io/editions/uni-link/ discussed here in the thread.

It's a new parser for the the TW link / prettylink detection: eg: [[test]]  ... it links to the tiddler named: test  but it shows a different text. Depending on the fields available at the "test" tiddler. If used like this: [[prettylink text|test]] it behaves as in existing TWs. No special function used. prettylink text will be shown.

eg:
title: test
caption: short title
subtitle: a tiddler to test the uni-link plugin

So if the tiddler has no fields it shows: test
If the tiddler has a "caption" field is shows:  short title
If the tiddler has a "subtitle" field it shows: a tiddler to test the uni-link plugin
If the tiddler has both fields: a tiddler to test the uni-link plugin

So the subtitle field wins. ....

This functionality is backwards compatible with existing tiddlywikis. So if tiddlers are copy / pasted between TWs, that don't have the plugin installed, it just falls back to the already existing behavior. Which imo is a nice idea, created by Mark S. in the first reply post.

There is a new parser "uni-link" that will be installed with the plugin. This parser is enabled by default an it will supersede the "prettylink" parser from the core. see: ControlPanel: Info: Advanced: Parsing

So if [[test]] is parsed it will be translated into a macro call like <<uni-link test>>, but with the nice twist, that it also works with a "fallback" if the plugin doesn't exist in a different TW.

@All .... Feedback very welcome!

have fun!
mario

[PMario]

On Friday, June 16, 2017 at 5:41:26 PM UTC+2, Stuart Amor wrote:

....  When creating the links its a lot easier to point them to the shorter tiddler title, but it would be nice to allow the previewed text (which is read by the uninitiated) to see the current long form.

Hi Stuart,

I would like to know, how your "uninitiated" users react, when they click a link "with a long text" and a tiddler with "a different title" pops up?
How do they find the right "search terms" .... and so on. Any related problems?

regards
mario

[PMario]

Just pushed a new version: https://groups.google.com/d/msg/tiddlywiki/pVqcVuNaTbA/ZB4w3T8lAQAJ
-m