Folks,
I have intentionally made some additional fields text areas before. If you want to retain the newlines you need to ensure you edit them through a text area, editing them as an input will destroy the line breaks.
I attach a draft solution I think many may fine useful. It provides a “local view template”. That is this view template is only for the current tiddler. This is good for experimenting on writing view Template tiddlers, but it is a multiline field with its own text area editor in edit mode so it allows you see what that approach looks like, and how I did it.
local-viewtemplate.json (5.0 KB)
However looking at the Original post of @DaveGifford I ask do you want the fields to operate as normal, only you do not need to scroll to see the whole field (if it value is long) but you can increase the display area with it wrapping over multiple lines?
Some thoughts;
- Of course I expect with the new freedom in fieldnames even the fieldname may be longer as well now.
- Remember there is now two ways to edit and view fields , one using tiddlers tagged $:/tags/EditTemplate to appear in the edit template.
Currently the fields use $:/core/ui/EditTemplate/fields to add and edit fields. But any field with a matching tiddler $:/config/EditTemplateFields/Visibility/tiddlername containing “hide” will not be displayed using the standard field edit, instead you can use another tiddler tagged $:/tags/EditTemplate to edit such fields (eg with text area and keep line breaks.
- The fact is in many cases if a field is a text area, rather than a single line field most filters work differently, eg you many need to use
{{{ [{Simple tiddler list}splitregexp[\n]] }}}
, they use the line break to split the items into separate titles.
What I am trying to say is the mechaisium is there to hack/handle this already however if you do you textarea rather than input there is a little more to it. So it seems to me you should make an effort when you want a multiline field, but leave the default to input.
Not withstanding this simply allowing an expanded view of long “input” fields would be nice, but the solution is not necessarily making them text area fields.