See attached TiddlyWiki
(Attachment list_links_issue.html is missing)
The behavior you describe (showing the tiddler’s caption field if present, even if blank)
is specifically described in the macro documentation (see https://tiddlywiki.com/#list-links%20Macro).
However, <<list-links>> is a merely a “convenience” macro for outputting a bullet list of links.
If you want a more specific behavior, you should use the <$list> widget directly, like this:
<ul><$list filter="...your filter here..."><li><$link/></li></$list></ul>
enjoy,
-e
…
However,
<<list-links>>is a merely a “convenience” macro for outputting a bullet list of links.If you want a more specific behavior, you should use the
<$list>widget directly, like this:
As Eric pointed out <<list-links>> is a convenience macro … and it is really “old” code, where the transclusion “title-fallback” code was the only possibility we had.
With version 5.2.1 we do have a lot more possibilities to create “filtered logic” … IMO the solution is relatively simple.
We would need to redefine the list-links macro a little bit. See the new <$set name="field-name" ... instructions.
\define list-links(filter,type:"ul",subtype:"li",class:"",emptyMessage)
\whitespace trim
<$type$ class="$class$">
<$list filter="$filter$" emptyMessage=<<__emptyMessage__>>>
<$set name="field-name" filter="[all[current]get[caption]!is[blank]then[caption]else[title]]">
<$subtype$>
<$link to={{!!title}}>
<$view field=<<field-name>>/>
</$link>
</$subtype$>
</$set>
</$list>
</$type$>
\end
I think I’ll create a PR with a suggestion to change this code and the docs in the core. …
@Eric could you have a second look at the new code.
-mario
Just for completeness. I was searching for other elements in the core that may have the same problem.
I found an old PR-discussion, which “scratches” the same topic: Base view/transclusion of translated titles on the presence of an "fr-title" field by xcazin · Pull Request #1191 · Jermolene/TiddlyWiki5 · GitHub
and probably has the same problems. …
So there are definitely some other elements which could / should be improved. … The downside is, that it will be much more work and it may eventually touch more core elements as I wanted to change 
So the way to go may be to make a proposal instead of a PR first.
-mario
…
So the way to go may be to make a proposal instead of a PR first.
I think the most elegant way to go is: Base view/transclusion of translated titles on the presence of an "fr-title" field by xcazin · Pull Request #1191 · Jermolene/TiddlyWiki5 · GitHub
We would need to have a closer look if there are unwanted side-effects.
-mario
@Eric Schulman @PMario
Thanks for the fast response and the solution.
I’m quite a newbie to TiddlyWiki and still try to grok the finer points.
-Reinhard
As a workaround you can redefine the core macro without modifying the core tiddler, if you
-
Create a new tiddler eg:
my-list-fix -
tag it with:
$:/tags/Macro -
put my code from above into the text
-
save.
Now your example should work. … Since user macros are defined after core macros it should work that way.
I did test it with your demo wiki.
The proposal discussion at github is here: [PROPOSAL] Possible improvement to show "caption" instead of "title" and "empty caption" fallback issue with TW lists · Issue #6397 · Jermolene/TiddlyWiki5 · GitHub
… You see: It seems to be an easy fix, but if done right it will trigger a bit more work.
have fun!
-mario
Actually, the change to <<list-links>> can be even simpler…
Just replace the <$transclude> widget with the <$view> widget, like this:
<$view field="caption"> <$view field="title"/> </$view>
The reason why this works is that, unlike <$transclude field="caption">, <$view field="caption"> applies its fallback content if “the field or property is missing or empty.”
However, neither suggested core change would actually address Reinhard’s stated use-case, which is:
“…to always display the title, rather than the caption.”
-e
1 Like
…
However, neither suggested core change would actually address Reinhard’s stated use-case, which is:
“…to always display the title, rather than the caption.”
Uuups, I didn’t read the whole thing … my bad.
But still the workaround is simple. my-list-fix can be
I did name the macro: my-list-links so it doesn’t overwrite the core
\define my-list-links(filter,type:"ul",subtype:"li",class:"",emptyMessage)
\whitespace trim
<$type$ class="$class$">
<$list filter="$filter$" emptyMessage=<<__emptyMessage__>>>
<$subtype$>
<$link to={{!!title}}>
<$view field="title"/>
</$link>
</$subtype$>
</$list>
</$type$>
\end
-m
Maybe some more remarks:
With the current situation, it is not possible to safely test filter expressions in “Advanced search”,
because, depending on the context, the same filter expression produces different results.
That’s a violation of the Principle of least astonishment.
I have a hard time to come up with a use case why I would want to mix (unknowingly or inadvertently) titles and captions in a list created with “list-links”. If I would want to look for captions, I would do so explicitly in my filter expression.
So, wouldn’t it be better, instead of making the “list-links” macro more complex to remove this special case (showing the caption, if present) completely and leave it to the user to search for captions if he wants to?
Right now, the “list-links” macro does more than is asked for:
- it outputs a bullet list of link, what is its stated purpose,
- but then it also chooses between the “title” and the “caption” fields.
So we have one function (macro), thats doing two totally unrelated jobs.
-Reinhard
Because the title field serves as an ID field, a title field, and a system field, the titles are often long and/or unwieldy. Having a fall back display field (e.g. caption) makes a lot of sense in that context. The tabs macro also follow this structure, since tab titles often need to be much shorter than the descriptive title of the tab.