Using the remove operator with titles from a function

1

Folks,

Please consider this code;

\function standarduser.fields() [enlist{StandardUserFields!!field-list}format:titlelist[]join[ ]]
\function core.fields() [enlist{CoreFields!!field-list}format:titlelist[]join[ ]]
\function custom.fields() [fields[]sort[]] +[remove<core.fields>] +[remove<standarduser.fields>] +[format:titlelist[]join[ ]]



* `<<standarduser.fields>>` <<standarduser.fields>>
* `<<core.fields>>` <<core.fields>>
* `<<custom.fields>>` <<custom.fields>>

At the bottom the first two list their titles, the third is not removing the first sets from the current set.

Most of our operators refer to a title list, why does remove say “an array of items to remove”.

How can I use remove or have the titles considered an array?

2

I believe remove is also expecting a title list. I didn’t try to recreate your transcluded lists, but the following works:

\function custom.fields() [fields[]] +[remove[background created text temp]] +[sort[]]

And so does this (when I added an ad hoc !!field-list to my testing tiddler):

\function core.fields() [{!!field-list}]
\function custom.fields() [fields[]] +[remove<core.fields>] +[sort[]format:titlelist[]join[ ]]

I took out the enlist + format:titlelist[]join[ ]] step because it’s three steps to end up back exactly where you started.

I’d also recommend moving your sort step to the very end of the filter, so you’re not sorting items you’re going to remove.

3

Thanks @etardiff I am getting lists via transclusion [{!!field-list}] and literals background created text temp but trying to remove items listed via a function seems not to be working.

In this case I can revert to the transclusion but it would be nice if remove<title.list> was working, so I can use a logical name, rather than needing to remember the tiddler/fieldname.

I am tempted to find a clear and simple set of rules to combine or remove items from one of more named lists of titles (or strings). If I cant get it I would consider custom operators OR new javascript operators.

4

I’m not sure why… it seemed to work when I tested the above code on TW-com. But if you’ve got a package of tiddlers you’re working with, I’d be happy to take another look.

Alternately, you could replace +[remove...] with -[enlist...] or use the fields:exclude suffix:

\function standarduser.fields() caption tags color icon +[join[ ]]
\function core.fields() title modified modifier creator created type +[join[ ]]
\function standard.fields() [<standarduser.fields>] [<core.fields>] +[join[ ]]
\function custom.fields() [fields:exclude<standard.fields>] +[sort[]format:titlelist[]join[ ]]

* `<<standarduser.fields>>` <<standarduser.fields>>
* `<<core.fields>>` <<core.fields>>
* `<<standard.fields>>` <<standard.fields>>
* `<<custom.fields>>` <<custom.fields>>

IMO, the absolute simplest way to do it is by using an additional filter run:

  • [enlist<my-var>] to add items (or simply [<my-var1>] [<my-var2>] +[join[ ]] if you want a title list as your output, as I did in \function standard.fields above)
  • -[enlist<my-var>] to remove them

But if you need to do it in a single filter run, we do already have prepend and append (which don’t deduplicate) and remove. I don’t think there’s a particular gap here.

5

Thanks, I see what you are saying, what you propose works, I suppose I did not understand why what I did was not working, but I do see why what you suggested does work.

  • the fields:include[] and fields:exclude[] were unfamiliar to me, and they do an existence test :clap:

A bit more research on my part to get a fuller picture.

by the way the reason I placed the literal list in a tiddler/field eg; {CoreFields!!field-list} was so new fieldnames could be added programmatically, otherwise we need to edit the function to add a fieldname.

  • The custom.fields supposed to be any field not in the core.fields or standard.fields as listed here https://tiddlywiki.com/#TiddlerFields which is different to your lists.
  • custom.fields then may be;
\function custom.fields() [fields:exclude<standard.fields>] +[remove<core.fields>] +[sort[]format:titlelist[]join[ ]]
\function custom.fields.here() [all[current]fields:exclude<standard.fields>] +[remove<core.fields>] +[sort[]format:titlelist[]join[ ]]

This seems to me that the standard and core field lists should be part of the core, and available to the designer, just like system tags that do not yet exist in the wiki but could. Part of why I am experimenting so I can put in a GitHub issue. The idea being once new core fields are added, they will be added to this list.

6

There are no standard fields, because they would be overwritten by users anyway, since every usecase is different. I for one would add all fields that I do want to exclude in an exclude-variable and not added to standard fields. So that would duplicate code, which in turn is confusing for other users

The only field necessary for a tiddler is the title. So is this the standard-fields variable.
A client server configuration has different fields than a single-file version
MultiWikiServer is different too.
tw-com defines a lot of fields too. Are they standard. IMO no they are use-case specific.

Just my thoughts.

IMO your last 2 lines of code snippets would be useful as an example somewhere in the filters-docs. May be somewhere linked to the fields-operator. Including the function definition, so users can play with it.