search

Chronoes / auto-xdcc

Automated downloader using XDCC in Hexchat
MIT License
7 stars 2 forks source link

Searching for exact match is case sensitive but probably shouldn't be #31

Open oosran opened 4 years ago

oosran commented 4 years ago

Let's kick this off with an example: Ponder two shows in the active list, let's call them "Babylon" and "Babylonia". We want to remove the first so we input /axdcc show remove babylon. Both Babylon and Babylonia are matched, so we need to refine the search keywords, but babylon is the full name so it's not entirely clear how to refine the query.

Apparently this is an issue with case matching, as inputting /axdcc show remove Babylon does match correctly and removes the show.

Suggested solution is to maybe make the search case insensitive.

It could be argued that an exact match should be case sensitive because it wouldn't be exact otherwise, but on the other hand you will most likely never encounter two different shows with the same name but different capitalisation airing in the same time span. So out of a UX point of view it's probably better if it's case insensitive.

Chronoes commented 4 years ago

There could also be a case where user wants to remove Babylonia but accidentally removes Babylon without thinking, because case-insensitive search matches exactly. We could add a CLI flag like --exact so only exact (case-insensitive) matches will be removed. If there is more than one match on initial query, one of which matches exactly, we can also provide the correct command to remove it for easy copy-pasting in the informational message. This acts well as confirmation too.

On Fri, Jan 3, 2020, at 13:53, Oosran wrote:

Let's kick this off with an example: Ponder two shows in the active list, let's call them "Babylon" and "Babylonia". We want to remove the first so we input /axdcc show remove babylon. Both Babylon and Babylonia are matched, so we need to refine the search keywords, but babylon is the full name so it's not entirely clear how to refine the query.

Apparently this is an issue with case matching, as inputting /axdcc show remove Babylon does match correctly and removes the show.

Suggested solution is to maybe make the search case insensitive.

It could be argued that an exact match should be case sensitive because it wouldn't be exact otherwise, but on the other hand you will most likely never encounter two different shows with the same name but different capitalisation airing in the same time span. So out of a UX point of view it's probably better if it's case insensitive.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Chronoes/auto-xdcc/issues/31?email_source=notifications&email_token=ACG3KCGLAPNUHGRXC4LIP6DQ34RLDA5CNFSM4KCMVAFKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ID3P3NA, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACG3KCGUJAGNXCKSPPHG653Q34RLDANCNFSM4KCMVAFA.

oosran commented 4 years ago

There could also be a case where user wants to remove Babylonia but accidentally removes Babylon without thinking, because case-insensitive search matches exactly. We could add a CLI flag like --exact so only exact (case-insensitive) matches will be removed. If there is more than one match on initial query, one of which matches exactly, we can also provide the correct command to remove it for easy copy-pasting in the informational message. This acts well as confirmation too.

That's a valid point I hadn't considered. Out of these two ways to deal with the problem I think the pseudo-confirmation in the form of a copy-pastable correct command would be the better option. To me it seems more helpful compared to having an additional CLI flag to deal with it.