How might I get past this stumbling block? I'm trying to advance a macro I built a few weeks ago. It prompts with a list of tags. Then inserts the chosen one at the cursor. Works great! Use it most days. The only caveat is that the user must select one of the already defined tags. The script does not accommodate the user's new input to be used as a new tag. Instead, the user must exit the script and retype the tag at the cursor if they are creating a new tag. Not done real often.
The zettelkastenTag variable is premade. Made by scanning 100's to 1000's of plain text files.
I'd like help with - when the user's input can't be matched in the list then take the user's input and put that in a separate variable so it can be added to the list and used as a tag in the current document.
I tried "If All Conditions Met Execute Actions" but the macro won't go on unless the user selects from the List.
This is part of the 'zettelkastenTags' variable #biases #book #conversation_skills #definition #dzogchen #economics #investing #lojong #medical #mental_models #mind_science #mindfulness #paper #quote #reading_strategies #sauntering
Good idea. I tried this out but found it less than ideal. Lots of keystrokes.
With the type-ahead search functionality of "Prompt With List" action, users only get >>Create-New-Item<< when they explicitly type >>Create-New-Item<< not when they are want to insert a tag and they find it is not in the variable list.
I agree this is not an optimum solution, but a quick workaround is when the user has typed a string that is NOT found in the list, then just press ESC to clear the entry, and then type "new" to find the >>Create-New-Item<< item.
Just make Create New Item the default value for the Prompt With List. Then you can either hit return (to add a new item) or start typing (to search for an existing list item). I do this with macros of my own.
I would have previously objected to that because often the user wants to see the list to choose from.
However, I just learned that if you type "all:" (or set the default to that), then all items will be shown, even if there are more than 100 items in the list.
A list designed to be appended is likely to (at least eventually) be long, so seeing the whole list is not particularly helpful. In any case, if you want to see the whole list AND have easy entry of new items, then make the default All:, and start the entry for the option to append with a character that's unlikely to be used otherwise, e.g, *Add Item. Then you could see the whole list, and simply typing * would bring up the option to add a new item. That's two keystrokes (* and return) instead of one (if new item is the default).
We discussed that very feature in the above link.
Actually, I don't think it would be that hard to simply add a button to Dan's search to "Add Item" using the current typed text.
My preliminary thoughts on doing this suggest this workflow:
Type a string in the Search box that is NOT found in the list
The "Add Item" button (and shortcut) are enabled.
The user clicks "Add Item" (or presses the shortcut) to close the search and the string that was typed is added to the source list for the search.
The problem is, the macro won't return what the user typed in the box. The macro returns the item selected in the list. It just uses the box to filter the list. If the box contains something that's not in the list, it returns blank.
If I were going to change this, I'd probably have to add an option that says something like "when the custom button is clicked, return the typed in text", or something like that. I'd have to think about it for awhile.
If we could figure out something that makes sense, it probably wouldn't be too hard to add, but since I haven't really looked into it in detail for awhile, I can't say for sure.
