Proposed change to library search

[chaley]

There have been several comments about the change to searching in V5.42 where naked (unprefixed) searches now ignore punctuation, spacing, and character variants (accented characters). Before it ignored character variants only.

I am considering adding a new search prefix, Kovid suggests '^', that forces the search to respect punctuation and spacing while ignoring variants. The existing search option "Unaccented characters match accented characters and punctuation is ignored" would have no effect in this case.

Examples using two titles:

1. "Big, Bothered, and Bad"
2. "Big Bummer"

Using a naked search with the option checked (V5.42 behavior):

• title:"g" matches both
• title:"g " matches both (the search is g<space>)
• title:"g," matches both
• title:"gb" matches both
• title:"g b" matches both
• title:"db" matches #1
• title:"," matches both (it actually matches all books)

Using the proposed prefixed search:

• title:"^g" matches both
• title:"^g " matches #2
• title:"^g," matches #1
• title:"^gb" matches nothing
• title:"^g b" matches #2
• title:"^db" matches nothing
• title:"^," matches #1

To summarize the proposed behavior:

• Naked search: either "contains ignoring punctuation and accents" or "simple contains" based on the existing preference. "Simple contains" is case insensitive matching where letter variants (e.g., accents) are significant.
• ^ search (new): contains ignoring accents
• = search: exact match ignoring case
• ~ search: regex based search

I am not interested in adding options to more finely control how naked and the new prefix search behave. There are too many places where searching is used so I can't guarantee behavior. I would consider adding another prefix to force "simple contains" if there is agreement on the prefix letter, and if Kovid agrees.

[ownedbycats]

I like the idea of the prefix.

Additionally: What about adding an option to quickly toggle naked search without going through the preferences dialog? If there's not enough room for another button, it could work in the search box context menu.

[dunhill]

Originally Posted by chaley

There have been several comments about the change to searching in V5.42 where naked (unprefixed) searches now ignore punctuation, spacing, and character variants (accented characters). Before it ignored character variants only.

I am considering adding a new search prefix, Kovid suggests '^', that forces the search to respect punctuation and spacing while ignoring variants. The existing search option "Unaccented characters match accented characters and punctuation is ignored" would have no effect in this case.

Examples using two titles:

1. "Big, Bothered, and Bad"
2. "Big Bummer"

Using a naked search with the option checked (V5.42 behavior):

• title:"g" matches both
• title:"g " matches both (the search is g<space>)
• title:"g," matches both
• title:"gb" matches both
• title:"g b" matches both
• title:"db" matches #1
• title:"," matches both (it actually matches all books)

Using the proposed prefixed search:

• title:"^g" matches both
• title:"^g " matches #2
• title:"^g," matches #1
• title:"^gb" matches nothing
• title:"^g b" matches #2
• title:"^db" matches nothing
• title:"^," matches #1

To summarize the proposed behavior:

• Naked search: either "contains ignoring punctuation and accents" or "simple contains" based on the existing preference. "Simple contains" is case insensitive matching where letter variants (e.g., accents) are significant.
• ^ search (new): contains ignoring accents
• = search: exact match ignoring case
• ~ search: regex based search

I am not interested in adding options to more finely control how naked and the new prefix search behave. There are too many places where searching is used so I can't guarantee behavior. I would consider adding another prefix to force "simple contains" if there is agreement on the prefix letter, and if Kovid agrees.

I was just thinking that as simple searches are made, this type of proposal would appear.
Thank you very much
And I hope it is possible to add that prefix

[jbacelar]

Originally Posted by chaley

To summarize the proposed behavior:

• Naked search: either "contains ignoring punctuation and accents" or "simple contains" based on the existing preference. "Simple contains" is case insensitive matching where letter variants (e.g., accents) are significant.
• ^ search (new): contains ignoring accents
• = search: exact match ignoring case
• ~ search: regex based search

I agree with the proposal.

[Katja_hbg]

I would prefer prefix for the new 5.42 behaviour as the «old» search is more common and well kown from other software.

E.g. I expect nothing for this search. title:"gb" instead matches both

[un_pogaz]

Originally Posted by Katja_hbg

I would prefer prefix for the new 5.42 behaviour as the «old» search is more common and well kown from other software.

E.g. I expect nothing for this search. title:"gb" instead matches both

Agree.

• Naked search: contains ignoring accents (if letter variants is check) pre-5.42
• ^ search (new): contains ignoring accents and punctuation (new mode)

Seems to me much more coherent and in the continuity of the behavior of Calibre had for years.

The only reason that could make "contains ignoring punctuation and accents" (as it is in 5.42) as the default mode, and not an extension/alternative, is that the demand for this exact behavior is very strong. I ignore it, is the case?

[DNSB]

I like the prefix idea rather than adding multiple buttons in the search dialog.

[Terisa de morgan]

I like the prefix mode idea (I agree too in prefix for new behavior, not the existing one.. see Smart Eject plugin, but that is another point).

[JSWolf]

I like the idea of putting the search the way it was pre-5.4.2 and making it have to be prefixed to be the new search. That way it's very easy to just ignore the new searcg if you don't want to use it.

[chaley]

Originally Posted by ownedbycats

Additionally: What about adding an option to quickly toggle naked search without going through the preferences dialog? If there's not enough room for another button, it could work in the search box context menu.

This almost certainly wouldn't work as you expect. The problem: virtual libraries. VLs are implemented as a wrapper around searches, e.g., (VL_search_expression) AND (user_search_expression). Toggling the option would change *both* search expressions, probably breaking the VL. A similar thing would happen with searches that contain saved searches.

The option in Search / Preferences is best treated as set-and-forget.

[chaley]

@most people who replied: The consensus seems to be to put the new behavior under the new prefix and to restore the previous behavior/option for naked searches. I emailed Kovid to ask if he is OK with this. More once that discussion completes.

[BetterRed]

Originally Posted by DNSB

I like the prefix idea rather than adding multiple buttons in the search dialog.

Are you referring to the search command on the main window, or the dialogue boxes in Advanced Search tabs?

[chaley]

Kovid is unwilling to change the behavior of naked searches for reasons I agree with. I will add the prefix.

[ownedbycats]

Will the prefix also apply to searching for accented characters?

[chaley]

Originally Posted by ownedbycats

Will the prefix also apply to searching for accented characters?

The prefix means

• character variants always match e.g., 'e' matches 'é', 'è', 'ê', and 'ë'
• spaces and punctuation are always significant.