Multiple 'Not' searches fail to remove items

[ChrisMillward]

I have a Genre column called Subject which allows me to create a hierarchy of my technical books, articles and theses.It also allows me the flexibility of referencing the same book under multiple subjects if it's not clear where to put it. However, I find that when I try to eliminate certain items from the display using CTRL and selecting the red minus for each category it doesn't work properly. For example, if I wish to remove 'Articles' and 'Thesis' I get:

not#subject:"=Article" or not#subject:"=Thesis" as the search.

So, with 2 Subject examples entries

Article,Microscopy.Atomic Force (Item removed)
Microscopy.Atomic Force,Thesis (Item Not removed)

It's search stops after the first item "Article" is checked.

But search expression:

not(#subject:"=Article" or#subject:"=Thesis") works fine for all

[kovidgoyal]

you need and not or betweenth eexpressions, click the little preferences button at th ebottom left of the tag browser and change search type to match all items.

[ChrisMillward]

Thank you Kovid. That works but at the same time reverses the sense of the green PLUS. I think, for me, I will use saved searches rather than keep changing the configuration. Incidentally when a saved search is executed the count shown remains at zero. I would expect it to show the number of matching items found.

[chaley]

Originally Posted by ChrisMillward

Incidentally when a saved search is executed the count shown remains at zero. I would expect it to show the number of matching items found.

Showing an accurate match count would dramatically affect performance. In the next release the zero goes away, showing nothing.

[ownedbycats]

Originally Posted by chaley

In the next release the zero goes away, showing nothing.

Nice! Thank you.

[ChrisMillward]

Not sure why it needed to go away or why it would affect performance as the number is already available on the bottom line [x of y books, z selected]. However, I have just updated and it has indeed 'gone away'

[ownedbycats]

Originally Posted by ChrisMillward

Not sure why it needed to go away or why it would affect performance as the number is already available on the bottom line [x of y books, z selected]. However, I have just updated and it has indeed 'gone away'

It was one of my requests; I asked here about the ability to cache the book count and also brought up the idea of just hiding the zeros entirely.

Saved searches can sometimes be very complex. For instance, I use this one for "books to read again" (mostly books I haven't read since last year or stuff with no last-read date, but it excludes a bunch of stuff too so I don't get stuff like game manuals or books I thought were crap):

(#read:true AND #lastread:true AND #lastread:<365daysago AND (rating:">2" OR rating:false)) OR (#read:true AND rating:false AND #lastread:false AND (not tags:"=.Documentation and Manuals" and  not tags:"=.Magazines and Periodicals" and  not tags:"=.Nonfiction") AND not #fanficstatus:"=In-Progress")

And I wouldn't be surprised if other Calibre users have saved searches that make mine look mild. So having Calibre calculate the number of books that fits that every time you edit a book's metadata would make it chug a bit. So saved searches are brought up on-demand.

[ChrisMillward]

I see so it's the recalulation required every time the tag browser pane is updated for some other reason other than executing a specific saved search.