Edit-list macro- how to save the selected item as a link instead of plain text

Is it possible to make the edit-list macro save the selected item as a link by adding square brackets around the title into the connected field? I wish to display the field’s value as a link in the tiddler’s viewmode so that I can click and navigate from there. I also plan to use the Relink plugin, and that will work only on links.

You could use the inputActions attribute to create an action that will update your target field separately. Note that your input and your target field might get out of synch this way … which may or may not be a problem.

<$vars bracel="[[" bracer="]]">
<$edit-text tiddler="$:/state/input"  inputActions="""
<$action-setfield myfield={{{  [<bracel>][<actionValue>][<bracer>]+[join[]] }}}
/>
""" />
</$vars>

Edit: Sorry – I thought you were talking about the edit-text widget.

The TiddlyTools <<edit-list>> macro is a combination of an $edit-text widget and a $select widget, and thus it handles input in exactly the same way as the TWCore, which behaves as follows:

If a $select widget is being used with multiple="yes" (i.e., to select a list of items to store in a field), then the TWCore handling automatically adds doubled square brackets around a selected item… but only if that item contains spaces in its value. However, if a selected item does not contain spaces, it will not be surrounded by doubled square brackets. In addition, using the $select widget without multiple="yes" will never add doubled square brackets, even if the selected item contains spaces, because the field contents are presumed to be a single value.

When using an $edit-text widget, the TWCore handling stores the input into the field exactly as was entered (i.e., it never adds doubled square brackets). Of course, you could type in the doubled square brackets by hand if you really want to, but it’s not something that should occur automatically, and I am very reluctant to consider changing the <<edit-list>> macro to accomplish this.

It’s also unclear how this would be done: it seems to me that it would be necessary to add the doubled square brackets after each keystroke, since changes to field values are updated immediately, and thus the stored value would need to always have proper brackets surrounding it. I suppose it might be possible to wait for an enter key or perhaps loss of focus to indicate an “end-of-input” event and only then add the surrounding brackets; however, in that case anything that depends upon the stored value would be broken until that "end-of-input: event occurs.

The idea of storing doubled square brackets in a field that contains a single text value – even if that value is always expected to be a tiddler title – comes up every so often. However, it is my opinion that this is a bad design strategy as it irrevocably binds the stored value with a specific expected use-case, and you may eventually find some other use-cases for that stored field value for which you will then have to explicitly strip off the brackets by doing something like:

<$vars lb="[[" rb="]]">
<$vars something={{{ [{!!somefield}trim:prefix<lb>trim:suffix<rb>] }}}>
...

So… instead of storing the brackets in the field value, a better approach when you want to display a field value as a link in “view mode”, would be to render a $link widget when the field value is retrieved, by using something like <$link to={{!!somefield}}/>.

WIth regard to the Relink plugin: although I haven’t used it myself, there is a way to configure the plugin to tell it that the values in specified fields are to be handled as tiddler titles, so that Relink can then update those fields when renaming tiddlers, even though the field value itself does not contain hard-coded doubled square brackets.
(see https://flibbles.github.io/tw5-relink/#Documentation).

-e

Thank you, Mark.

And, thank you Eric for your detailed explanation. I think I should do what you suggest, display the value as a link using the link widget. I don’t know why I did not think of this before. It’s a straightforward and logical thing. And for the situations where there are multiple values, that would be handled by the Multiple attribute, as you have pointed out. That should solve it. Thanks!

Thanks for the reply, Mark!