Whoops, everything's gone. This seems like a bug (attention, @peternlewis?) to me—if the input is all removed, the box should default back to what was set in the initial call, i.e. all: should repopulate, thus showing the full list again.
Or is there some other workaround that I'm not seeing in order to get the list back? As far as I know, that box is completely non-traceable, i.e. I can't see what anyone has typed into it until they press Return, so there's nothing I can do when they make its contents vanish.
griffman,
I don't think this is a bug. It is by design. The "all:" is just like any other text that can be set as initial filter value on prompt show. In prompt list, "all:" means to show all items. To show the full list again, you can just type "all:" again.
I know you can do that, but not everyone using the macro will know that, and there's no way to prompt them about it once they've reached the "no list showing" point.
Maybe not a bug, but if not, then a very useful feature would be an option in the gear menu to revert to initial state if the input box is empty.
If I could somehow notice they had nothing in the input box, I could handle it, of course. But I don't think that's possible.
The wiki states more than 100 items, but in my testing it was more than 99.
Maybe there's a technical reason the action works this way (> 99 items requires all: to populate the list), but if there is not, I'd prefer it populate the list with the null prompt. That way, if the user were to backspace to remove their typed entry the list would repopulate—like it does now with 99 or fewer items.
For now, my strategy is to avoid all: if possible.
I have a list with 100+-ish items in it (and which will grow), split across a dozen or so categories. I don't think it's a good user experience to have the user have to dive into each category, then back out again, especially as they can currently add multiple entries in one shot.
So for now, 100+ is a sort of unavoidable situation, unless I really want to complicate the process, which I'd rather not do.
Yes, that's why I'd prefer the action to not require all:. But I also thought others reading this (that might have a list under 100 that could grow to 100+) would benefit from the approach I've used.
@griffman, if the Prompt With List worked as it does for <100 items, would that meet your needs?
As macdevign_mac says, this is not a bug, it is a feature. You could just as well use “e” as the search string to search for all things if you were confident every entry had an “e” in it. “all:” matches all, and so it displays all.
The 100 limit is a performance and usability limit - displaying a single scrolling list with 100+ items in it is not a useful UI in general. If you think 100 is ok, then what about 1000, or 10000 items. Everyone might have a different number, but the limit itself is obvious. So at that point it is a judgement call as to what the limit is, and 100 is the judgement I made. Currently there is no way to configure this number, and I'm not sure there ever will be.
As for reverting back to something else if the user empties the search field, that would be a very weird UI, likely prone to speed issues if the user types quickly.
Thanks for the explanation, Peter. And in general I agree that 100+ is not a usable list as a lump, but in this case, it's categorized, and makes much more sense as one screen to look through than a series of 20 pages of six entries each.
I'll just add an explanatory pop-up that they can disable after seeing it once.
