Call to Macro failing, even though I seem to be passing the right parameters

#1

I’m building up a somewhat complex filter string to pass to a macro. The string is building correctly, and I’m checking that it is passed correctly to my macro (by logging the parameter to the screen), but the macro seems to be ignoring parts of this query.

I anonymized the demographic data being used, and posted a copy of the wiki to

https://crosseye.github.io/TW5-demos/2023-08-27a/.

In the sidebar you will see links to Everyone, Democrats, and so on, as well as a More Queries section with ones like All Women, Ages 40 - 50.

Those are the main point of this wiki. You can use the “copy clipboard” links to get lists of email addresses formatted for an email TO / CC / BCC input boxes.

But I want users to be able to create their own queries. So I’ve been building Create Query, which allows users to select demographic and party information to filter the list of users.

With some help from saq and others, I have this almost working. I will eventually add a “Save Query” button, but first, I wanted to check it inline. The generated queries are working fine when I cut and paste them into their own macro calls, but somehow when I use them directly from here, they fail. You can see the macro call at the bottom of the Save Query tiddler.

While it shows all 319 people by default, when you update some of the selections in the colored boxes at the top, the correct query is generated, but doesn’t filter things correctly. (Note that I’m not yet doing anything with Age – I’ll get there!) This debugging output shows that the query is properly reaching the macro:

 *** Query (inside macro) ***: "<generated filter>"

But unlike the hard-coded ones, it’s not running properly. It properly selects all People, but then does not apply any of the subsequent filters. When I plug its output into a hardcoded call to the macro, it does do the filtering. I’m stumped as to why. Any advice would be appreciated.

Bonus Question

(because one is never enough!)

Does anyone know anything about the OokTech GenTags plugin? While it’s functioning properly to add tags in the “Choose Streets” section, the actual tags both in the selection list and when appended to the body are gigantic! Anyone know how to fix those sizes back down to something more normal? Or is there some newer plugin or built-in mechanism to add a Tag-like editor to my view?

#2

https://crosseye.github.io/TW5-demos/2023-08-27a/#%24%3A%2F_%2Fmacros%2Femails

<h4>*** Query (inside macro) ***: "$query$"</h4>
<h4>Found: <$text text={{{ $query$ :filter[has[email]] +[count[]] }}} /></h4>

The use of $query$ in the first line is not a good way to troubleshoot the use of $query$ in the second line. The reason is because the first line will be fully wikified whereas in the second line everything between the triple braces will be parsed as filter syntax.

Using this for your debug output is more helpful:

<h4>*** Query (inside macro) ***: "<$text text=<<__query__>>/>"</h4>

and it gives this output

*** Query (inside macro) ***: "[tag[Person]] <<gfilter>> <<pfilter >> <<sfilter >>"

manually run the above query and you will see the undesired results.

If you want to use variable filters, better to use operators like subfilter and filter. I didn’t test this, but maybe something like it will get you closer:

[tag[Person]] :and[filter<gfilter>filter<pfilter>filter<sfilter>]
1 Like
#3

Are you talking styling? Or is it somehow much content? If the former, could you link to an example showing it?

#4

Of course. It’s the styling. The functionality is perfect. In Create Query, if you expand the Streets choice (by choosing its second radio button) and enter the tag name area, it shows a choice of tags that for me looks like this:

image
image1824×1506 191 KB

. All the tags have far too much top, left, and bottom padding. But it is even worse when they’re selected:

image
image1824×1506 189 KB

Those are just monstrous! I did try to find the css culprit, but didn’t spend too much time on it, as the other issue here was paramount. I am reasonably adept at CSS but it keeps eluding me. I guess I should really test this on a blank 5.3.1 wiki and make sure that it’s just me and not an incompatibility the plugin has, though. I’ll go do that.

#5

OK, it’s not me. If I download this: GenTagStylingIssue.json (33.6 KB) onto an empty edition, it has the same styling errors.

Does anyone know if this is being actively maintained? @inmysocks?

#6

Interestingly, the styling is a consequence of a bug I found just yesterday!!!

The native vanilla stylesheet, i.e $:/themes/tiddlywiki/vanilla/base
has a style for

button.tc-tag-label, span.tc-tag-label {
	...
	white-space: break-spaces;
	...
}

There exists no such value for white-space and should probably be changed into:

	white-space: normal;

AFAICT, this resolves your issue.

Alternatively, you can create a small custom stylesheet for it with:

button.tc-tag-label, span.tc-tag-label {white-space:normal;}
1 Like
#7

Timing! Thank you very much. This solves my problem for me.

Do note that w3schools – while much better than it used to be – is still often behind the times. break-spaces is a legal value. I’m not sure for how long. However, it is not the right value for me here. Perhaps later, I can look to see what is giving all that extra space. But it’s definitely ugly. And this fix does exactly what I need. Now to fix that orange! :slight_smile:

Thank you for the help!

#8

I played around more and came up with the following. Replace this:

<$let
  genders = {{{ [enlist{!!genders}] +[sort[]] +[join[,]] }}}
  parties={{{ [enlist{!!parties}] +[sort[]] +[join[,]] }}} 
  streets={{{ [enlist{!!street-names}] +[sort[]] +[join[,]] }}} 
  gmatch= ":filter[[<<genders>>]split[,]match{!!gender}]" 
  pmatch = ":filter[[<<parties>>]split[,]match{!!party}]" 
  sfmatch = ":filter[[<<streets>>]split[,]match{!!street}]" 
  gfilter= {{{ [{!!choose-gender}match[yes]then<gmatch>else[]] }}}
  pfilter = {{{ [{!!choose-party}match[yes]then<pmatch>else[]] }}}
  sfilter = {{{ [{!!choose-streets}match[yes]then<smatch>else[]] }}}

  query-string = "[tag[Person]] <<gfilter>> <<pfilter >> <<sfilter >>" 

>

with this and it is closer to working:

<$let
  genders = {{{ [enlist{!!genders}] +[sort[]] +[join[,]] }}}
  parties={{{ [enlist{!!parties}] +[sort[]] +[join[,]] }}} 
  streets={{{ [enlist{!!street-names}] +[sort[]] +[join[,]] }}} 
  identity="[all[]]"
  gmatch= "[<genders>split[,]match{!!gender}]" 
  pmatch = "[<parties>split[,]match{!!party}]" 
  sfmatch = "[<streets>split[,]match{!!street}]" 
  gfilter= {{{ [{!!choose-gender}match[yes]then<gmatch>else<identity>] }}}
  pfilter = {{{ [{!!choose-party}match[yes]then<pmatch>else<identity>] }}}
  sfilter = {{{ [{!!choose-streets}match[yes]then<smatch>else<identity>] }}}
  
  query-string = "[tag[Person]filter<gfilter>filter<pfilter>filter<sfilter>]"

>
  1. Single angle brackets for variables within filters
  2. Used [all[]] as the identity filter for the else.
  3. Used the filter operator
#9

Thank you very much. I went down a rabbit-hole on another part of the project and haven’t had time to look at this yet. It’s bedtime now, but l’ll try it tomorrow.

Thanks!

#10

It does and the setting is needed for TW core UI

#11

Yes, there is - you should avoid w3schools and stick to MDN: white-space - CSS: Cascading Style Sheets | MDN

EDIT: Didn’t spot @pmario’s post :man_shrugging:

#12

Or wrong, indeed. The problem is, it’s not vetted by trusted orgs, devs or anyone with web-dev credence.