Hello! I've been using ATT for a few weeks and I'm loving it. I'm happy to see it's so active on github too.

A feature I think'd be useful is a filter for the mini-list, controllable by a hotkey. Essentially the same as the ctrl-p plugin for vim if you're familiar.

If you think this is useful/interesting, I'd be happy to take a shot at implementing it and submitting a PR. I've no wow add-on experience, but it'd be fun to try it out! If so, I'd appreciate any implementation advice or suggestions you'd have.

Workflow

1. User hits keybind
2. Small input box appears over the mini-list
3. As user types, each item in the list is filtered for anything that contains the given keyword
4. User hits ESC or clicks an X in the input box to clear the filter

Search

• A search matches an item if the item's name, description, or categories/tags contain the search text.
  • If an item matches, show the item and all parent containers leading to it
  • Searching Bushtail would likely leave only one category chain: Elwynn Forest->Rare->Bushtail
• A search matches a container (e.g. Pet Battles, Rare, Elwynn Forest) if the container name contains the search text.
  • If a container matches, show everything inside it regardless of matching or not.
  • Searching Pet Battles would show [Elwynn Forest->Pet Battles->[Black Lamb, Cat, ...], Stormwind->Bet Battles->[Rat, Cat, ...] ]

Use Cases

• search toy to show only quests/items/achievements/etc with toy in them (name, description, categories/tags). Should show every item inside 'Toy' containers.
• search Tharynn Bouden to search for anything that matches. This'd be to search for an NPC and reveal everything related to them.
• Target NPC, hit keybind, filter auto-populates with the target's display name and performs the same searches as above (Not sure how useful this is since you already have the tooltip text, but I think you'd get this for free).

Dev/UX considerations
For 3 I imagine performance is a big concern, I'm not sure how many container rows you're dealing with in total, or how easy it is to filter the items from being displayed. We'd want to cache as much as we can, and use a debounce on the filter input update.

For 4 we'd want to be careful on how the user exits the text input, it should be seamless. It's a huge pain when you're typing in some input box, forget about it or not exit it properly, and you get stuck trying to use WASD.

Edge Cases/Open Questions

• Would this filter the current list (given all settings-menu filters, e.g. only show for current zone), or temporarily remove all filters and just use the search keywords?
  • It may be useful to search, for example, for ICC achievements while you're doing an Ulduar run.
  • On the other hand, searching broad terms like Toy may be too noisy if you're including Toy categories from every zone in the game.

The problem with this and why we haven't implemented, as we've had others as in the past, is that we store no information on the item names themselves. It's all done by itemID's so that every language translates. Due to this it makes it not possible to do searches or filters on names only the id's themselves which isn't useful and changes on each language.

What may be A, B, C to english could be P, Z, A in another while a third has T, N, I.

Due to this, is also why the ATT search is limited to "/att itemID:####" #### = actual itemID or /att

Got it, makes sense. If this has come up before, you've probably already considered most implementation ideas I could come up.

For my curiosity though :) It seems possible to keep a separate cache/trie of search terms->IDs in memory by calling GetXInfo(id) on each ID in your list, storing it, and refreshing it any time the general list updates. After inputting the search text, build a list of IDs that match your search, and then filter the general list for IDs that match that.

Any thoughts or concerns about this approach? I don't think the performance/overhead of maintaining the cache would be too bad as long as you don't have too many elements and keep it to a prefix search.

Again, little experience with wow addons, so I'm not sure what all of the limiting factors are here.

The problem with that is if we were to try to cache all of that information for the search, your game client would crash. Well over a gigabyte easily.

Thank you for your detailed suggestion, but due to the nature of searching for text in an environment like ATT where we don't store it, we ask the API for it, there's a short delay (15-200 MS per request). That delay would sometimes cause the search to be non-functional or incomplete. The search behaviour to cache the text would be extremely slow. As such, it is not feasible to do this.