Possible bug in list-links macro

[Reinhard Engel]

See attached TiddlyWiki

[Eric Shulman]

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

[PMario]

On Friday, January 14, 2022 at 1:24:16 PM UTC+1 Eric Shulman wrote:

...

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

[PMario]

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: https://github.com/Jermolene/TiddlyWiki5/pull/1191

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

[PMario]

On Friday, January 14, 2022 at 3:50:23 PM UTC+1 PMario wrote:

...

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: https://github.com/Jermolene/TiddlyWiki5/pull/1191#issuecomment-65532894

We would need to have a closer look if there are unwanted side-effects.

-mario

[Reinhard Engel]

@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

[PMario]

On Friday, January 14, 2022 at 4:10:06 PM UTC+1 reinhard...@gmail.com wrote:

@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.

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: https://github.com/Jermolene/TiddlyWiki5/issues/6397

... You see: It seems to be an easy fix, but if done right it will trigger a bit more work.

have fun!

-mario

[Eric Shulman]

On Friday, January 14, 2022 at 6:26:11 AM UTC-8 PMario wrote:

On Friday, January 14, 2022 at 1:24:16 PM UTC+1 Eric Shulman wrote:

...

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.

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

[PMario]

On Friday, January 14, 2022 at 4:35:41 PM UTC+1 Eric Shulman wrote:

...

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

[Reinhard Engel]

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.

On Friday, January 14, 2022 at 3:50:23 PM UTC+1 PMario wrote:

[Reinhard Engel]

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

[Mark S.]

On Friday, January 14, 2022 at 8:50:34 AM UTC-8 reinhard..wrote:

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.

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.