I was getting some weird results trying to use wofi with my dmenu-style i3 container nav script. Windows from a previous session showing up in the results. I noticed that if I ran just wofi -d with no stdin, the stale results still showed. I found wofi -d loads results from a cache and merges them with stdin. This doesn't seem right.
ah, i realized the cache is tracking previous selections, which is useful.
So the bug is that it's displaying cached items even if they aren't present in stdin (may effect other modes too).
This can be solved my setting the cache file (-k/--cache-file) to /dev/null, thus reading nothing.
This is actually just how caching works right now. Cache results are imported first so they display at the top of the selection area and no stale cache checks are being done. This occurs in all modes, in dmenu it's just the most obvious. There probably should be some sort of stale cache checks to avoid this as currently uninstalling a program will cause it to still receive an entry in run/drun mode.
Sorry this took so long to get to. Cache invalidation should be implemented by c13921329da0
~scoopta oh, I was just checking on this and was surprised to see you've implemented it, thank you! 🎉 Tested latest with my custom dmenu sway nav scripts and no more zombie cache entries clogging the top 10. 🧟