Template language changes

[chaley]

18 Oct 2024 (in calibre 7.21)

New template function

• list_count_field()
  

  list_count_field(lookup_name)

  returns the count of items in the field with the lookup name lookup_name. The field must be multi-valued such as authors or tags, otherwise the function raises an error. This function is much faster than list_count() because it operates directly on calibre data without converting it to a string first. Example: list_count_field('tags')

[ownedbycats]

This will be useful!

[Comfy.n]

Very useful indeed, thank you! As this provides sorting for multi-valued fields, I can see myself doing less searches like authors:#=2, tags:#=3 and so on.

I've just tested it and have already set two columns using:

program: field_list_count('tags')
program: field_list_count('authors');

Is the semicolon needed, BTW? I'm never sure.

[chaley]

Originally Posted by Comfy.n

program: field_list_count('tags')
program: field_list_count('authors');

Is the semicolon needed, BTW? I'm never sure.

A semicolon ending the last line of a template is optional.

Truth: according to the syntax it is illegal. Coding the template language parser to optionally accept it was easier than not, and it doesn't hurt anything.

[ownedbycats]

I ran into a slightly strange issue when counting a custom column. Template tester it works right:



But when I try to modify my #timesread composite:



The expected number displays in the book list but not book details.

Spoiler:

Yes, #datesread is a taglike. I also tried restarting and the error persists.

[Comfy.n]

I did a test out of curiosity and got the same for a probably identical column, as you have helped me populate it: on template tester it's ok as well as in the book list; on BD, it gives #readdates' is not a field - line number 1

Anyway, in my case the readdates/datesread gets populated only by the Mark as Read chain, which runs on double-click event, and it does increment #timesread already.

[ownedbycats]

Yeah, I used to use a manual integer for #timesread too, but then I realized that the list_count composite would work instead.

Since field_list_count() is faster, it'd be ideal if it works for this use-case.

[Comfy.n]

Originally Posted by ownedbycats

Since field_list_count() is faster, it'd be ideal if it works for this use-case.

I noticed it sort a tad faster than list_count, initially.

Originally Posted by ownedbycats

Yeah, I used to use a manual integer for #timesread too, but then I realized that the list_count composite would work instead.

Oh, I see! I remember now that you've shared the list count template with me and now I can picture another advantage over the integer: it means one less action on my double-click event chain. Will do some tests with the composite instead, thanks.

edit: I just tested list_count instead of integer on 7.20 stable and it meant a visible speed improvement on the double-click chain. Running from source I can use field_list_count but the timings are different from regular use.

[chaley]

Originally Posted by ownedbycats

I ran into a slightly strange issue when counting a custom column. Template tester it works right:

Attachment 211486

But when I try to modify my #timesread composite:

Attachment 211487

The expected number displays in the book list but not book details.

Spoiler:

Attachment 211488

Yes, #datesread is a taglike. I also tried restarting and the error persists.

Fix submitted.

In the meantime simply ignore the error. The error happens because of how the template tester is used in this case (editing a composite). Calling field_list_count() works in a composite. Until the fix is in source there might be a few log messages.

[chaley]

Originally Posted by ownedbycats

I ran into a slightly strange issue when counting a custom column. Template tester it works right:
[...]
The expected number displays in the book list but not book details.

Ignoring the error doesn't fix the book details problem, but the submitted fix does.

Here is a copy of the changed file (calibre/utils/formatter.py) if you want to try it before @kovid accepts the change.

[ownedbycats]

thank you!

Looking at the pull request, it was just forgetting to account for custom columns?

[chaley]

Originally Posted by ownedbycats

thank you!

Looking at the pull request, it was just forgetting to account for custom columns?

There are 2 commits. The first changes how field_list_count() checks if a field exists, using a faster more reliable technique. The second, the one you note, fixes the underlying problem that has been there for some 10 years. The second is not required by the first.

[ownedbycats]

The changes are now in Calibre source

[chaley]

23 Oct 2024 (in calibre preview 7.21)

New template binary operator inlist_field

• inlist_field does the same as inlist except that the right-hand expression must evaluate to a field (column) name. This operator is much faster than inlist because it doesn't convert the field contents to a string. In addition, it works on fields that use a separator other than comma, for example authors. Note that the operator requires the field name not the value, so using $tags will not work. Example:

  'foo$' inlist_field 'tags'

[ownedbycats]

so for a custom column, it's just #whatever?

EDIT: I pulled the latest changes but I am not seeing inlist_field.