[TW5] Seek empty value field

[Changhoon Lee]

I am trying to search field which does not have any value (empty space).

I can see these fields in user fields so It does exist somewhere.

I tried '[has[field]]' as a filter.

I don't know what filter I can use to find these tiddlers.

Lee

[Tobias Beer]

Hi Lee,

 

I am trying to search field which does not have any value (empty space).

Please report this on GitHub.

I believe this to be a design flaw in TiddlyWiki,

where undefined and empty string are interpreted as identical,

which, obviously, they're not ...for any practical purposes.

Best wishes,

— tb

[Erwan]

Hi Lee,

I think you can do it this way, even though it's probably not very efficient:

<$list filter="[!is[system]!has[f]]">
  <$list filter="[all[current]fields[]regexp[^f$]]" variable="ignore" >
    <$link><$text text={{!!title}}/></$link>
  </$list>
</$list>


Erwan

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/2e04ecbe-4091-4769-be39-f0e7fd3e12fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tobias Beer]

 Hi Erwan,

 

I think you can do it this way, even though it's probably not very efficient: 

<$list filter="[!is[system]!has[f]]">
  <$list filter="[all[current]fields[]regexp[^f$]]" variable="ignore" >
    <$link><$text text={{!!title}}/></$link>
  </$list>
</$list>

Cool stuff although confusing and yes, possibly inefficient.

I always expect has[foo] to contain tiddlers having a field foo even if its value was empty

and so I'd very much hope the core can be adapted to work that way.

At least, I don't see why it wouldn't / shouldn't.

Best wishes,

— tb 

[Jeremy Ruston]

Hi Tobias

I always expect has[foo] to contain tiddlers even if the value of foo is empty.

I guess that's just me.

I agree that it’s strange. Looking at the code, the extra check for the field being empty was added explicitly in January last year:

https://github.com/Jermolene/TiddlyWiki5/commit/1c283c55865b3b128101c26f60d594313764c621

It’s too late to change the semantics of the existing operator, but I’d certainly be interested in backwards compatible ways of addressing the problem in the original post.

Best wishes

Jeremy

Best wishes,

— tb 

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/58c12440-3be6-4a19-9281-87836d92954c%40googlegroups.com.

[Erwan]

Hi Jeremy and Tobias,

I always expect has[foo] to contain tiddlers even if the value of foo is empty.

I guess that's just me.

I agree that it’s strange. Looking at the code, the extra check for the field being empty was added explicitly in January last year:

https://github.com/Jermolene/TiddlyWiki5/commit/1c283c55865b3b128101c26f60d594313764c621

It's true that it's a bit counter-intuitive, but I would assume that it's more common to use "has" or "get" in order to do something with the field value, and in these cases it's more convenient not to have to check if the value is empty before using it. That's how I interpreted it at least ;)

It’s too late to change the semantics of the existing operator, but I’d certainly be interested in backwards compatible ways of addressing the problem in the original post.

the first idea that comes to mind is to add a field operator "empty[f]" (or "empty-field[f]"), which keeps the tiddlers as input only if they have a field "f" with an empty value (removes both the ones which don't contain a field "f" and the ones in which "f" has a value).

Cheers
Erwan

Best wishes

Jeremy

Best wishes,

— tb 

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/58c12440-3be6-4a19-9281-87836d92954c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/0C4C6B4E-34AE-42EC-8D9B-5BFDD81B30E1%40gmail.com.

[Matabele]

Hi

I don't know the reasons for the specific choice of output -- it seems, however, that a more useful logic would have been:

"[has[F]]"  -- those input tiddlers in which field F exists

"[!has[F]"  -- those input tiddlers in which field F does not exist or has an empty value

In which case "[has[F]] -[!has[F]]"  -- would return those tiddlers with a non-empty value for field F (the original output of "[has[F]]")

In the case that this introduces backward compatibility issues -- a suffix option could be added for the has[] operator -- for any suffix:

i.e. "[has[F]]"  -- those input tiddlers in which field F has a non-empty value

      "has:suffix[F]]" -- those input tiddlers in which field F exists

      "[!has[F]]" -- those input tiddlers in which field F does not exist or has an empty value

      "[!has:suffix[F]" -- those input tiddlers in which field F does not exist

regards

On Tuesday, 10 November 2015 20:02:29 UTC+2, Jeremy Ruston wrote:

Hi Tobias

[Tobias Beer]

Hi Erwan,

 

It's true that it's a bit counter-intuitive, but I would assume that it's more common to use "has" or "get" in order to do something with the field value, and in these cases it's more convenient not to have to check if the value is empty before using it. That's how I interpreted it at least ;)

That is true for get, but I would not agree that it is for has. To me "empty value" is or at least should be a value, meaning: not the same as "undefined". But yes, there are practical applications where I presume one would want to subsume "undefined" as "blank".

A) as for has:

Perhaps the has filter operator can be given some suffix to tell it to also include those that are blank, e.g. any of:

has:field[some-field]

Meaning: get all tiddlers that have the field, regardless of whether or not a value is set.

B) As for get:

Not sure, but I believe we cannot add "empty items" to a filter set, e.g. ["foo","","","bar baz"]... for whatever reason... so they essentially get removed. This may be problematic for some situations where you actually want empty items, e.g. if you first iterate titles (in a pseudo-column A) and then again iterate the same number of items (in pseudo-column B) while retrieving a given value with respect to them. At that point, you may not want items to get omitted just because they were empty / or undefined ...but rather want the empty value.

One way — assuming that would not break other filters — would be to allow something like:

get:empty[some-field]

...to instruct the iteration to also index blanks, possibly assuming undefined to meaning blank.

So that, if I did:

<$list filter="[tag[HelloThere]get[foo]]">
value: <<currentTiddler>>
</$list>

...with only one tiddler tagged HelloThere having the field foo defined, I would still get a list with the amount of items of whatever number of tiddlers have the tag HelloThere.

Best wishes,

— tb

[Tobias Beer]

Hi Matabele,

 

"[has[F]]"  -- those input tiddlers in which field F exists

"[!has[F]"  -- those input tiddlers in which field F does not exist or has an empty value

For me, negation should always be proper negation in terms of set theory. If a filter defines a set, then its negation needs to define the exact complement with respect to all available members, so that A && !A = ALL.

In which case "[has[F]] -[!has[F]]"  -- would return those tiddlers with a non-empty value for field F (the original output of "[has[F]]")

While this kind of optimization would work as you intend, I find it highly confusing.

So, considering how things stand atm, to me it should be:

• has[f]
  all items where the field f is defined and non-empty (as is)
  
  
• !has[1]
  all items where the field f is not defined or empty (as is)
  
  
• has:field[f]
  all items where the field f is defined, empty or otherwise (tbd)
  
  
• !has:field[f]
  all items items that do not have field f (tbd) — so, no items where the field exists but is blank

 Best wishes,

— tb 

[Tobias Beer]

Hi all,

I went ahead and created an issue for this:

#2065 has:field

https://github.com/Jermolene/TiddlyWiki5/issues/2065

If agreed upon, it should be quite straight-forward (for me or anyone else) to work out the details and make a PR.

Best wishes,

— tb

[Jeremy Ruston]

Hi Tobias

For me, negation should always be proper negation in terms of set theory. If a filter defines a set, then its negation needs to define the exact complement with respect to all available members, so that A && !A = ALL.

You’ve made this point before. However, it is not true of the current filter operators, nor can we retrospectively fix it. So, that boat has sailed, and we have no choice but to continue to use “!” for the more informal sense of “inversion” that we use at the moment.

Best wishes

Jeremy.

In which case "[has[F]] -[!has[F]]"  -- would return those tiddlers with a non-empty value for field F (the original output of "[has[F]]")

While this kind of optimization would work as you intend, I find it highly confusing.

So, considering how things stand atm, to me it should be:

• has[f]
  all items where the field f is defined and non-empty (as is)
  
  
• !has[1]
  all items where the field f is not defined or empty (as is)
  
  
• has:field[f]
  all items where the field f is defined, empty or otherwise (tbd)
  
  

• !has:field[f]
  all items where the field f is not defined at all (tbd)

 Best wishes,

— tb 

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/ca8b2d01-7750-43ca-8023-408f440941dc%40googlegroups.com.

[Tobias Beer]

Hi Jeremy,

 

You’ve made this point before. However, it is not true of the current filter operators, nor can we retrospectively fix it. So, that boat has sailed, and we have no choice but to continue to use “!” for the more informal sense of “inversion” that we use at the moment.

I'm aware of that and had to learn to accept that there are no intentions to change existing filters in that regard, even if the amount of things fixed was greater than that of things that could possibly break. However, that does not mean that we should encourage such patterns for future filter implementations / modifications in turn.

Best wishes,

— tb