Help with finding the attachment to a post in a mailing list archive

[vuk]

Since I’m very far from fluency in customizing TiddlyWiki, my current strategy is to first bet on my problems already being solved and search for solutions.

Currently I’d like to control the order the fields of a tiddler appear in edit mode. I think I found a discussion about it and even a proposed solution that would suit me just fine [tw] Is there a way to customise the ORDER of fields in the EDITOR?

The problem is an attachment is mentioned and I just don’t see it. Am I blind or the mailing list archive has it stripped off?

@pmario I think that is your post, do you happen to remember the context?

[pmario]

Here is the link to GG: https://groups.google.com/g/tiddlywiki/c/t5EQ_IqOnSY/m/zz_A9RVWAwAJ

But the problem is, that the fields-template is 8 years old now. So the concept is OK, but it would be better to use the latest code.

It contains a tiddler named: field-sort … This can be any name. If you want to hide it from your users add $ to make it a system tiddler. The body just contains a list of space separated field names.
and $:/core/ui/EditTemplate/fields which overwrites the core field template. If you use a different name than field-sort you’ll also need to adjust this tiddler with the new name. .. It’s only one change.

Text copied over from GG

[vuk]

The diff against the original shadow tiddler is quite big, but I suppose it’s because I’m diffing the modified template for a years older version against 5.3.6

I suppose the relevant change is in this filter, which takes the custom order of fields from the user defined tiddler:

-<$list filter="[all[current]fields[]] :and[sort[title]]" variable="currentField" storyview="pop">
-<$list filter=<<tf.config-filter>> variable="temp">
+<$list filter="[all[current]fields[]] +[sortby{field-sort}]" variable="currentField">
+<$list filter=<<config-filter>> variable="temp">

[pmario]

@vuk

I suppose the relevant change is in this filter, which takes the custom order of fields from the user defined tiddler:

Yes – I think that’s right.

That’s how the code looks, when it is changed. The second code line, with the purple mark contains the changed filter with :and[sortby{field-sort}]

Screenshot with tiddler edit mode and config tiddler

[vuk]

I have to admit that my first thought (even before I started to look in the docs), was that by analogy, it would be nice if I could control the field order via having a list field somewhere. As I understood, that was technically difficult.

Your approach uses a whole tiddler to store the custom ordered list, which is fine for me. But how come this never made it into the core after years, that it didn’t become a vanilla hidden setting? Personally I think that the need of custom field ordering is quite generic, yet I’m aware I’m biased about it, since there’s a conflict of interest because I need this feature for a particular use case.

If I go and modify the edit template shadow tiddler, I’ll have to maintain the change and it would require manual intervention over and over with each TiddlyWiki version update, no? Why not having the vanilla template process a shadow tiddler with default empty value and if the value is not empty (was modified by user) to use that as custom ordered list of fields in the filter instead?

[pmario]

I think the approach from Eric described at: The Order of Fields in Edit Mode - #2 by EricShulman is even better.

If the {$:/config/fieldSortOrder} tiddler does not exist, it uses the default sort by title approach. Otherwise the config tiddler will be active.

<$list filter="[all[current]fields[]] +[sort[title]sortby{$:/config/fieldSortOrder}]"
   variable="currentField" storyview="pop">

[pmario]

@vuk

Your approach uses a whole tiddler to store the custom ordered list, which is fine for me. But how come this never made it into the core after years, that it didn’t become a vanilla hidden setting? Personally I think that the need of custom field ordering is quite generic, yet I’m aware I’m biased about it, since there’s a conflict of interest because I need this feature for a particular use case.

That’s always a question. For the core we need functions, that should work for “as many usecases” as possible in a backwards compatible way. – I did have a look. The code is about 10 years old. So modernizing it with the latest functions we have available would probably be worth it. …

It may be worth a try, to discuss Eric’s approach. – On the other hand, we already have 26 hidden settings and imo 100+ official ones in the ControlPanel.

I personally would like a possibility to “drag & drop” sort the list – but that would be a completely different thing and relatively complex.

An other approach would be to define a filter cascade to handle field-lists based on templates. This function did not exist 10 years ago. So it would be worth to do some experiments, since it does provide maximum flexibility, at the cost of added complexity.

Just some thoughts