p0deje / Maccy

Lightweight clipboard manager for macOS
https://maccy.app
MIT License
12.43k stars 529 forks source link

Visually separate fuzzy search with regular search #270

Closed pekcheey closed 1 year ago

pekcheey commented 3 years ago

==== Problem ==== with fuzzy search turn on, my search for a number string "149" return me list of fuzzy search result. While the fuzzy search feature is good, it might be good to somehow indicate that the results are from fuzzy searches

==== Expected 1 ====

I should be able to tell which results are from fuzzy searches. Perhaps via some color coding somewhere?

==== Expected 2 ====

and if possible, allow both exact and fuzzy search results to be displayed along side each other.

since exact search result should be more relevant, it should be sorted at the top of the result.

the normal searching use case would be to try to key in a couple of characters and ideally the clip will either be in an exact result match. failing which it might appear in a fuzzy result match.

p0deje commented 3 years ago

Currently you either search by exact match or fuzzy - there is no way to mix those two right now. Do you want to mix them somehow failing back to fuzzy when no exact match is found?

pekcheey commented 3 years ago

Yup. I think that would be good to mix them up. Because I cannot think of a usecase where one would prefer the fuzzy search results over the exact search results.

There should, however, be a visual indication to differentiate the exact search result from the fuzzy search result. This is because it is possible that there is no exact match and all the result comes from fuzzy match, and the user will need to copy the snippet from source again.

I remember seeing in an other issue that exact searching is faster than fuzzy searching. I would suggest that Maccy first display the result of the exact matches. Then after a user configurable delay (because the exact matches might already includes what the user is looking for), spawn another thread (so as not to hang the UI) do the fuzzy matches. And add the result to the result to be display.

p0deje commented 3 years ago

There are plenty of users who prefer fuzzy search so I don't think that's true.

Implementing a more sophisticated search is going to be big as there are multiple use-cases we need to consider.

  1. User-configurable delay, but it should always be instant and I don't think it has to be configurable.
  2. Separate thread won't work in this case as the performance issues of fuzzy search are related to constant redrawing of the menu. There is no way to do this asynchronously in Cocoa.
  3. Visual representation. How that should look like? Do we want to show an "f" symbol in the search bar? If yes, what about users who disable the search bar at all? If no, do we want to indicate each result that came from the fuzzy search?
  4. Users can be confused by the fact that at first, they were seeing fewer and fewer results (while the exact search was in use) and then they suddenly could get dozens of results (when the fuzzy search kicks in). I'm not sure how to overcome this.

In general, I'm fine with implementing this making sure it's user-friendly and lightweight, but don't have time and energy to invest right now. PRs are welcome!

pekcheey commented 3 years ago

There are plenty of users who prefer fuzzy search so I don't think that's true.

I knew I'm quite the odd ball. :D

  1. having no delay is fine so long as we have a good visual representation point 3 . Or perhaps the problem can be mitigated by adjusting the fuzzy sensitivity. I'm all for fuzzy search, but hopefully we can alleviate the problem of having a wall of bad matches with short search strings.

  2. Performance is a separate issue. But this article might be helpful https://www.hackingwithswift.com/articles/210/how-to-fix-slow-list-updates-in-swiftui The idea is that the slow performance might be cause by internal List comparison . does this help? I'm not a Cocoa programmer. But I see a lot of sorting going on inside of Menu.swift. My understanding on the matter is that sorting should generally be done once, as close to the presentation as possible. But like I said, I'm not a Coaca programmer...

  3. I would prefer that the indication being inlined with the search result. this would give some context to each result without needing to mentally co-relate the result with a indication somewhere else.

  4. I imagine that this could be bridge with a small icon representing each different state located at the right end of the search bar. with a different icon representing a different search stage. i.e. exact search will have it's icon, fuzzy search will have its icon, search commplete will have an icon. come to think of it. the Maccy title on the left of the search bar could be overloaded for the purpose. i.e. on search complete, "Maccy" will display. when fuzzy searching it could be displaying something like "Maccy Fuzzing" when exact searching it could be displaying something like "Maccy Matching"

p0deje commented 3 years ago

having no delay is fine so long as we have a good visual representation point 3 . Or perhaps the problem can be mitigated by adjusting the fuzzy sensitivity. I'm all for fuzzy search, but hopefully we can alleviate the problem of having a wall of bad matches with short search strings.

I can only recommend building Maccy locally and experiment with fuzzy search settings in https://github.com/p0deje/Maccy/blob/master/Maccy/Search.swift#L12. Maybe there should be a different threshold or even configurable.

Performance is a separate issue. But this article might be helpful https://www.hackingwithswift.com/articles/210/how-to-fix-slow-list-updates-in-swiftui The idea is that the slow performance might be cause by internal List comparison . does this help? I'm not a Cocoa programmer. But I see a lot of sorting going on inside of Menu.swift. My understanding on the matter is that sorting should generally be done once, as close to the presentation as possible. But like I said, I'm not a Coaca programmer...

Unfortunately, it's not related to sorting at all - it's purely insert/remove NSMenuItems in NSMenu. There is not much we can do about it as it's getting slow with 200+ items.

p0deje commented 1 year ago

In the new version of Maccy, there is an experimental "mixed" search which is a combination of all the searches order by most restrictive to least restrictive:

  1. search using exact search;
  2. if there are no results, search using regular expressions;
  3. if there are no results, search using fuzzy search.

Hopefully, it would allow to forget about using specific search mode and there will be no need to differentiate between them.

Feel free to re-open if original issue still exists.