"Prompt With List" Not Searching as Expected

[August]

I'm trying a simple Prompt With List test:

I want to be able to press a [Return] or c [Return] and get the appropriate selection; I'm assuming that the search for a match in the list begins ats the beginning of the strings. (Note: the details of the search/match process are not explained in the manual page, which seems geared toward mouse input rather than keyboard.)

But the above test does not work as I expect it to. When I type a [Return] or b [Return] I get the a and b results, as expected. But not because of the filtering that I expect. When I type a[Return] the list is not filtered, but the a choice is first, so it works. When I type b[Return] the first item is filtered out, leaving b and c, with the b the first choice, and it works. But when I type c[Return] I get the a result because typing c does not exclude anything from the list, all entries are shown, and the [Return] selects the first choice in the list.

What am I not getting about how this works, and how can I make it work the way I expect? I can make variations on the prompts, but I really would like them all to be able to start with a character like "[", if possible. If I put the "[" character in as the default, it's in the search string, but it doesn't stay there when I type a single letter, so the behaviour is as before, unless I start typing with a Right Arrow keystroke.

I can't be the first person to trip over this, but I haven't been able to find anything in the Wiki or Forum so far. If this has been explained elsewhere, please advise!

Thanks.

[UPDATE] I marked Peter's explanation in post #18 as the solution, along with his post #20, which confirms my guess at a fix, based on the explanation. His comment in post #18 refers to "the above list" which is not the example list in my original question, he is referring to the example list in post #16.

[_jims]

@August

But the above test does not work as I expect it to.

Hi @August. When you type a single character, the action displays all items in the list that contain that character (ignoring case). So when you type...

• a : all three items are displayed because all three include an a

• b : the last two items are displayed because they both include a b

• c : all three items are displayed because all three include a c

With your existing list, you could type a], b], or c], then return

Or if you want to type only one character to display your choice, then that character must be unique to that item in the list. For example:

[1] Choice A
[2] Another Choice
[3] Beyond A and B

[August]

Thanks Jim (@_jims),

I have another use of Prompt With List where it's the actual initial character that I type, and even if the character appears elsewhere, if it's the first character, it's sufficient. In this list:

I can type r, s, e, t, m, or a and even though all of those letters appear in Keyboard Maestro, the choice will be executed as I desire.

I suspect the problem is the fact that in this test case it is not the initial character. That's what I was testing and it looks like it doesn't work as I had hoped.

It appears that there's a two-step process (which I recall, possibly, being explained somewhere but it's not in the User Manual and I couldn't find it elsewhere) where if there is a match to the initial character, that takes precedence, and when that option is eliminated, then it's a search for matches anywhere in the prompt string. It does not, as I was presuming, keep searching from the front, it only does that to disambiguate IF there is a match of initial characters. It's an either or, starting at the first character or otherwise starting anywhere in the string.

Perhaps if I could somehow "front load" the search string to start with the "[", where a keyboard character would follow that, rather than replace it, then I could make that choice in a single keystroke. I tried setting "[" to be the "default" and it appeared in the search field, but I had to type a Right Arrow to keep it there so that I could then type the letter choice, and that isn't what I want.

Or perhaps I could use the technique in The “Follow Menu Choice with Return” Macro (v0.5) and instead of having the single-key macro send a character and a Return, it could send three or four characters.

In any case, it looks like my test demonstrated how "Prompt With List" actually works, and it's not the way I was hoping for at first.

Thanks.

[Nige_S]

@August

Perhaps if I could somehow "front load" the search string to start with the "[", where a keyboard character would follow that, rather than replace it, then I could make that choice in a single keystroke.

Do you need the leading [? Leave that out and you're back to your desired behaviour of initial character match.

[August]

@Nige_S

Do you need the leading [?

No, not absolutely, but I like the aesthetics of it.

I'm looking for a "syntax" to use in filenames that would not be used otherwise, that would identify the filename as corresponding to the name of a Desktop Workspace, where the syntax identifies the hotkey letter that activates that Desktop. Square brackets are allowed in file names and they "look right". I'm very invested in having the look and feel of this be "intuitively right", whatever that means.

The names in the screenshot of above of my Desktop names are the names I use in the CurrentKey app, which keeps track of the names, switches desktops, and recognizes when other apps have switched desktops. But it has a built-in limit of 16 characters in a name and it's no longer available. I'm working on replacing my dependence on that with something that has more flexible naming and that isn't dependent on a discontinued app.

I suppose that there are relatively few files anywhere that start with a single letter and a space, so I could probably just use that as the "syntax". But I want this to be robust and I like the visual context supplied by the brackets even before you recognize what letter is there. Also, starting with a non-alpha character will sort all files of that type together in any list of mixed files.

I'm thinking that to help ensure that I don't trip over "legitimate" uses of brackets around a single letter in a file name, I could use something like "[A]] A Desktop Name", that's even less likely, or I could separate it from regular text by using special Unicode characters, e.g.,〖A〗, ⎡A⎦, ⊑A⊒, ⟥A⟤, ⧉A⊞, ⫷A⫸, etc. -- highly unlikely to have conflicts, but anything that doesn't start with a keyboard character has the same problem with the "Prompt With List" choices.

Any thoughts on which of those markers above say "Desktop Workspace" to you?

Thanks

[Nige_S]

@August

Any thoughts on which of those markers above say "Desktop Workspace" to you?

Totally understand your thinking with all the above, but I was wondering if you could use the "Friendly Values" trick so your list items would actually be eg [a] Choice A__a) Choice A and so on -- you'd get "priority selection" on the first character of the friendly value but still have the underlying data in your chosen format.

It does changes the aesthetics of the list presentation, but you may have to live with that to get everything else you want.

[August]

I like the "Friendly Values" concept, but it seems awkward here. List items will be generated from existing window titles, which will be determined by open filenames (or in the case of things like the Notes app, existing content). I want those to be readable and easily identifiable as what they are, i.e. names that identify the Desktop Workspace that they are in, a Desktop Workspace Identifier (or DTWSID, which seems aesthetically preferable to DWI).

To use Friendly Values for the list items, I would have to either live with those Friendly Values in the file name or convert back and forth regularly so that the awkward FV constructions only appear in the Prompt With List menu.

I believe that I can avoid needing the Friendly Values by using the same technique as in The “Follow Menu Choice with Return” Macro (v0.5). That works by setting a macro group to be active for only one action.

There is one macro in that group that is defined to have multiple hotkeys, every one of the 40+ text keys that might be used as a menu choice in the PWL menu.

When that macro is activated by a keypress, it spits out the text %TriggerValue%%Return% and then automatically deactivates -- so that individual text keys won't continue to be followed by %Return%.

I believe I can create a new version of that which also includes the preceding character(s), whether simple text or Unicode, so that upon a single keypress, what is given to PWL is the complete string, from the initial character. That way, even if the initial string somehow happens to be used later in a name, it still won't match.

[Nige_S]

@August

To use Friendly Values for the list items, I would have to either live with those Friendly Values in the file name or convert back and forth regularly so that the awkward FV constructions only appear in the Prompt With List menu.

It's a trivial bit of text processing to create a Prompt List from your File List -- and you don't have to convert back because what's returned from the Prompt action is the "unfriendly" part, ie your original format.

It's certainly an easy way, though I'm sure that your and other methods could also be made to work.

Demo, replacing your eg [a] prefix with a) to make things obvious:

Prompt with Friendly Test.kmmacros (4.6 KB)

Image

[August]

Thanks. Yes, massaging the content of a list using a regular expression to parse the pieces is pretty straightforward. I appreciate this example. I will probably copy it at some point.

But it is not working as desired.

I run this macro and the PWL menu/list is presented to me.

I type c and the PWL dialog shows:

If I follow c with [Return], which is my intent so that I can use "Follow Menu Choice With Return" and get a choice activated from a single keystroke, then what appears is:

That is not making sense to me, because that c is the first character of the new menu entry. As I described above, I can have a menu where the first entry is "K Keyboard Maestro" and have other entries starting with e, o, a, r, m, s, and t without having any conflict, the desired line gets chosen. I don't get why this is different.

Does it work that way for you?

Thanks .

[_jims]

@August

But it is not working as desired.

@August, maybe you know this already, but you can select each option with three keystrokes, e.g., 2 ] return

---

On a related note...

If you are using this PWL to execute different macros, have you considered using a Conflict Palette rather than a PWL?

[Nige_S]

@August

But it is not working as desired.
...
I type c and the PWL dialog shows:

That's odd -- when I run it and type a c I get

...as expected.

An OS version thing? Language settings, maybe? Not a clue, but if you post your OS and KM version numbers and any localisation preferences that aren't "UK English" I'll see if I can replicate the issue.

[August]

@_jims

you can select each option with three keystrokes

Thanks. Yes, I'm aware. I'm trying to minimize keystrokes.

Ultimately (after I get the bugs worked out) this will be how I change Desktop Workspaces, which I do dozens of times an hour, or more. Ideally I wouldn't have a menu, I'd just have a separate hotkey for each choice, but I haven't found a way to have all 21 hotkeys (and hopefully more) have the same pattern of ⌘⌥A or ⇧⌃⌥A modifier keys. If I mix modifier key patterns, I make mistakes, and that leads to unintended consequences because programs like Chrome have hotkeys in that space that do things like "Close All Windows", etc.

Right now, I type either ⇧⌃⌥Z, if I'm on the laptop keyboard, or ⇧⌥⌘Z if I'm on the external keyboard (because the keyboards are different and I want muscle memory to be the same) to bring up the menu of Desktops. Then I type one unmodified keystroke, which is set up as a single-stroke hotkey as described above.

That's been the smoothest, fastest, and most comfortable for frequent use that I have been able to come up with. Three keystrokes after I get the menu up is too much, if I have a choice.

[August]

@_jims

have you considered using a Conflict Palette rather than a PWL?

Thanks for the suggestion. Yes, I have. It could work, and would probably work well, except for one design consideration that I have.

To use a Conflict Palette requires that every entry be a macro. Because these are choices of Desktop Workspace names, I would have to define a separate macro for each and every Desktop, all triggered by the same ⇧⌃⌥Z hotkey, and then selected from the Conflict Palette. Once set up, that could work very nicely.

But the catch is that I don't want to have to define my Desktop names within KBM macros. As far as I know, a Conflict Palette will display the names of macros that all have the same hotkey, which means that changing the name of a Desktop requires going into the KBM Editor and finding the proper macro to change. Lots of overhead, IMHO.

I want to be able to simply, intuitively, and transparently give a desktop a name somewhere very accessible from each Desktop, without interrupting my work much at all, and then have that name be captured and displayed in the Menu. That means I want to generate the list on the fly, each time, so that it automatically includes any changes to the Desktop names. I don't know how to do that with a Conflict Palette. I imagine there could be a programmatic way of making changes to KBM macros, but that seems unnecessarily complicated. I guess that means that what I want is for the "source of truth" for Desktop names be outside of KBM.

What's working so far is to generate a list of current Desktop names and save that into a KBM list, then put that list into the Prompt With List menu. I currently have the convention that all Desktop names start with the letter that is their hotkey in the PWL menu. Any changes I make to Desktop naming during my work get automatically captured and presented the next time that I want to change Desktops, which may be only a few seconds later. Going into the KBM Editor is not required.

I'm attempting to make something that works at least as well for me as the CurrentKey app, which is no longer available. My new system doesn't have to have anything like all the CurrentKey features, it has to have my features. A primary one is easy desktop renaming, on the fly. I would also like to overcome CK's limit of 16-character Desktop names, which my current plan has no trouble with.

Thanks for the questions. It's helping me clarify my decision making.

[August]

@Nige_S

if you post your OS and KM version numbers

MacOS Version 10.14.6 Mojave
Keyboard Maestro Version 10.1.1
Language Settings:

Another buggy thing. Typing a and b at the PWL show the full lines, as expected, in the top field, but c is displayed differently. I don't have a clue why.

However, this is chasing a bug out of curiosity. For me, this is fortunately not (yet) affecting my actual macro development.

[August]

By the way, @Nige_S,

I really appreciate your Prompt With Friendly Test macro, especially:

I had no idea that KBM had that kind of support for regular expressions. That's wonderful. REs are second nature to me, I've been using them for 49 years.

I modified your code slightly. Instead of there being a space at the front of %Variable%Local_theRest%, I moved it outside the RE capture group and explicitly added it to Local-promptList because that's the part of the string that I think of as the Desktop Name, separate from the leading Hotkey. The space is a delimiter, not part of the content.

Thanks!

[August]

I'm stumbling over another Prompt With List where it's picking an item based on characters anywhere in the list item and not giving priority to the first character.

Here's the list:

And here's what I get when I type "3":

The bad news is that I cannot type simply "3[Return]" because that gets me a choice of "2"!

That's so counterintuitive that I cannot think straight about alternatives. The only one I've found suggested in the forum (earlier in this thread) is to edit the list so that the initial character is unique for each entry. That is again totally counterintuitive.

A better, but still kludgy, workaround might be to create unique menu choice strings, rather than single characters, such as "{3}" at the beginning of the line, and then use a technique like what I did here to spit out the whole menu choice string when a single character is pressed.

MACRO: “Follow Menu Choice with Return” (v0.5)

How to “immediately” choose a "Prompt With List" menu option [UPDATE v0.5] I initially published my v0.2 version of the macro here. Other people, particularly @Sleepy, made suggestions, some of which I incorporated. So I have updated this long description of the macro and how I built it with notes about the updates. The conversation that lead to those updates thus follows this post in this thread and time is seemingly warped. (See the movie "Predestination" for more warping of cause and effect.) …

Come to think of it, that will probably work fine, but it still seems to be a kludge to Prompt With List working counterintuitively and not simply selecting based on the first character typed.

@peternlewis -- Maybe that could be an option to PWL, Spotlight Mode or First Characters Mode?

[Nige_S]

@August

I'm stumbling over another Prompt With List where it's picking an item based on characters anywhere in the list item and not giving priority to the first character.

Can you post the relevant parts of your macro, to save us trying to type in your list exactly from the screenshot? Earlier in the thread, a similar bug on your machine was working as intended on mine and it'll be interesting to see if the same's true here.

[peternlewis]

@August

The bad news is that I cannot type simply "3[Return]" because that gets me a choice of "2"!

Keyboard Maestro orders the entry by a machine learning system. So initially with the above list, if you typed “3” and it had no other information, it would select all the lines with 3 in them, and it does default to selecting the “3” at the start. However, if you then actively select a different entry, Keyboard Maestro will remember that, and in the future, if you type “3”, it will select the one you have triggered the most in response to the “3” selection.

I would guess that you have actively selected the 2 entry after typing 3 in the past. Select the correct entry a few times and Keyboard Maestro will learn.

Some of this is dependent on your Prompt With List settings.

[August]

@peternlewis

I would guess that you have actively selected the 2 entry after typing 3 in the past.

Yes, I probably have, frequently.

On one hand, I was stepping through the entries to test the macros and I did sequenced where I selected 3 and then ran it again and selected 2. At that point I was making sure that the macro performed all the expected steps and didn't notice whether or not it was making exactly the change that I expected. I was assuming that it made the choice I expected so I was typing the hotkey to bring up the menu, ⌃⌥⇧M, and then a number, then Return. So I may well have pressed "3 [Return]" without noticing that I was actually selecting 2, so I may have trained the system in the erroneous choice.

@peternlewis, Is there a way to reset the learning so that I can be more careful about how it is trained?

Would restarting the KBM engine be enough? Rebooting? Or create a new PWL Action? I would think that if I simply duplicated the existing action and deleted the original, KBM would see that as a different menu and start learning about that one from scratch. Would that work?

[peternlewis]

@August

Is there a way to reset the learning so that I can be more careful about how it is trained?

Duplicate the Prompt With List action and delete the original.

@August

Would restarting the KBM engine be enough? Rebooting?

No.

@August

I would think that if I simply duplicated the existing action and deleted the original, KBM would see that as a different menu and start learning about that one from scratch. Would that work?

Correct.