Jump to content


  • Content Count

  • Joined

  • Last visited

About donut

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'm not a fan of these kinds of exchanges. We have a communication disconnect. Thanks for your help. And again, not intending to be difficult, just trying to understand and be helpful. Apologies for the frustrations I've caused.
  2. I see. So inferring, Alfred already trims the results list to 20 or 40 at search time. I'm wondering about similar situations in which any search would be polluted similarly. "ABC" having results like "A-B-C", for example. It would be tedious to prime each query if it happens a lot, but if it doesn't, this is manageable. I'll do my best. @deanishe I didn't get the impression you acknowledged it was a bug, either. The impression I got was this is normal, expected behavior. But now we've clarified. Thanks for your explanations.
  3. Sigh... Which you didn't really need to do in depth. I'm just a sole user and "can't fix" would suffice. Sorry to bother. Thanks for doing this. Thanks. I'll give this a try. I can tell I'm frustrating you both, and you're kind enough to still engage. While I now understand Alfred's model for results ordering makes filtering and additional sorting difficult and particularly performance-constrained, I still don't understand why while searching for "RTS" being polluted with results containing "RT-S" isn't considered a bug from a user and product perspective. Wou
  4. No, it won't. I can't select the result (Yes, I read the link; selection is required according to 1 and 2.), because I can't find the results, because of the number of matches, because Alfred is not matching properly. It's a bug from a user's perspective because the matching isn't right. The returned set of results is incorrect. But I can see you've made up your minds. I thought it might be helpful to point out the results are wrong and try to work through solutions, but I don't know the implementation contraints. I'm just a random user. I'm good. Sorry to bot
  5. I think there's a way to achieve some of these goals without changing the search, just the rendering in the ViewController. For me, the bottom line is: Alfred is returning incorrect results. This is a bug. Results for "RTS" are being polluted with "RT-S". I don't think "Well, it's the metadata server" is a good reason for why (from a user's perspective, while it might be a good root cause for the developer). Those polluted results are preventing me from finding the most obvious, most intuitive results, which to me in this use case are the highest in the folder hierarchy
  6. I don't feel we're connecting. When I said "quirks," I wasn't talking about performance characteristics, I was talking about the metadata search treating "RTS" and "RT-S" as the same, which I gleaned was a surprise, given the first response to my inquiry. I don't know the implementation costs, obviously, and I don't mean to overtrivialize, so please don't characterize me as purposefully doing so. I'm just making a user-oriented argument for why wrangling with the complexity is worth it, but as I noted before, I'll deal.
  7. I think this is a false assumption, and this part: ... is rather exactly the point. Alfred is relying on this metadata search API too much, and passing the buck, and the user experience suffers. I don't think users should have to know the underlying implementation and work around what's effectively an excuse for bad results. Really? Does the metadata search always return too many results to handle? Why put Alfred's UX at the mercy of the metadata search alone, something that clearly has shifting behaviors? In my example, it treats "RTS" a
  8. ...or with a more intuitive sorting of results. Folders like node_modules and bower_components and the like make limiting the number of folders inconvenient for developers. Alfred simply doesn’t support this use case efficiently. And it’s totally fine to limit the audience for a product. Value and implementation cost have to be balanced.
  9. Well, my example is one where a tighly focused search isn't possible, because of the explosion of results by default. So I had to remove search space by excluding an entire folder of work from the index, because Alfred defers order to the system outside of its control, rather than deploying a pattern of intuition. I've used Alfred for years, so while I'm disappointed that something so simple seems out of scope, I've got it for now. It just means Alfred can't handle the use case of having hundreds of folders and files that are intermingled with the logical results.
  10. It looks like the workflow approach is the right one, but I'm having trouble making this part of the default search behavior. For the time being, I've just excluded the parent folder from the Spotlight index, and I'll just deal. Thanks!
  11. Thanks for the reply! I familiar with most of this, except the workflows recommendation. In my case, there are so many false matches that I can't find the one I want, so I can't even select it to give it any preference (even with 40 results shown). But that's also only a solution for this particular query; I'd have to do this for nearly everything. Unlike what Alfred help page says, I don't think the default ordering is even taking hold. When I execute `mkfind`, the second result is the one I want. In Alfred, it simply doesn't show up in the first 40 hits. Also, when I
  12. I'm searching for a folder with the query "RTS", which I expect to result in "~/Dropbox/RTS". It's an exact match I'm looking for the target folder name. However, the results I get are deeply nested, dozens of matches like: "~/workspace/keyboards/qmk_firmware/lib/chibios/demos/STM32/RT-STM32F103-OLIMEX_STM32_P103" ... which is quite counterintuitive to me. In fact, most of my results are like this; deeply nested fuzzy matches ("RT-S" vs "RTS") are dominating the results in a way that I can't find the simplest matches, which I expect to be the exact matches higher i
  • Create New...