Due the lack of my own abilities, I had to stand on the shoulders of a giant namely the brilliant @tiffle to come up with this idea.
The problem: with certain apps (in my case Numbers, Bear Notes, DevonThink, SimpleMindPro, Scrivener and others) there are too many macros to remember Keyboard Shortcuts, palettes are huge (a lot of time wasted looking for a specific macro in the palettes), occupy too much screen real-estate. Using Keyboard Shortcuts to trigger many different palettes is not a solution because becomes tedious to see palettes constantly flashing on and off the screen. I tried multiplying the number of nested and conflict palettes but it's not the answer.
Current Situation.:
@Tiffle created a superb macro which allows users to quickly create pick lists of macros
I use it many times a day but there is one drawback: constantly having to trigger the "Get List" macro → type the search string in the search box → press Enter to execute the macro, after which, most importantly for this discussion, the search box disappears and the Get List macro must be launched again to trigger another macro.
My idea
To use a variant of @tiffle 's pick list method but have the app specific search pane ("select entry" below) remain permanently on the screen after the macro is triggered. It is small and unobtrusive and its width could be configurable.
I don't mean to distract from your topic's argument, but may I suggest a primitive hack relating to this…
I'll assume that you are absolutely right in terms of your setup, needs etc. and I won't repeat tips about how to optimise the use of keyboard shortcuts so that they are easier to store in "muscle memory"!
If memorising hotkeys is the main issue, how about having your own plain text "cheat sheet" appear when active application is active? I suppose my thinking is starting to converge with @Nr.5-need_input's suggestion, in your related topic ' Wish list: ability to scroll up and down palettes'), of using an HTML prompt, but if a cheat sheet is all you really need, maybe a plain text file would suffice.
Thank you for your suggestion. I did that years ago and I still have them, and it's not a solution for me. I am far beyond that stage of my evolution with KM.
Oh, I don't doubt it. I was just thinking of an alternative to palettes as a list of hotkeys, really… but I know you want to move beyond all that.
I wonder if you had the time to read any part of a topic I started recently, 'How I limit which macros are listed by “macro by name” '. Despite the inventive replies, I stuck with my original hacky method since it suited my way of doing things, but regardless, maybe there are some ideas in that thread that you could build upon.
I had missed that related topic. It seems closely related.
Hi @ronald - I have an idea about how to achieve what you're asking but to test it out I need you to upload a macro for me to modify. I can't promise to reply quickly but I will try to.
HE has arrived ! Thank you so much for replying ! Please take your time.
I imagine that I would have to get rid of the last "deactivate" action which is not a problem.
Well, that's what I wondered… I didn't say how closely related the topics were, because, on first try, I was a bit unclear about @tiffle's subroutine so I need to focus on it when I have time. I shall then be qualified to say. Various alternatives to my hack approach were suggested in replies to my topic. If I recall correctly, some of the initial replies weren't dealing with the core issue of in terms of what I had in mind, so I am not going to assume that something looks similar is the same.
At the core, we are discussing variants of pick lists. The problem with pick lists is both the time it takes to set them up as well as the maintenance.
It all looks nice on paper. When you start creating and modifying the underlying lists you are enthusiastic and full of energy, but that energy wanes as time goes on and you (at least I) end up neglecting the list and going on to something else. Among my macros, I have countless pick lists that I have not maintained. 99% of them.
The genius of @triffle's method is that it is based on macro groups. Setup takes a few minutes, and there is no maintenance. Whenever you modify, add, subtract macros from a macro group, the change is automatically implemented in @triffle's Get List pick list referenced in my initial post which I why I still use the same Get List macros every day, the same ones I created when @tiffle s post came out.
It sounds different, then, and true to the topic's title.
I presume that "already built into KM" refers to Trigger macro by name.
My aim, and eventual system, was to have the Trigger macro by name prompt provide access to all active macros, filtered by what I knew I would actually want to see. For instance, macros that were only ever to be triggered by, say, a hotkey, would not by default clutter up the results of my typing in the prompt.
In case you missed the conclusion to my post[1], which should perhaps been a "TLDR" at the start:
Yeah I wanted to avoid that kind of overhead. With my method, if I find that I want an active macro to appear in the list, I add the unusual character "．" to its title, ad hoc.
I did see that topic of yours @kevinb and just skimmed over it and, at the time, I thought it was similar to what @ronald and I had come up with. BUT that's as far as my "analysis" went so if I get time I'll go back to yours to get a proper view. It may be that your hard work can be used to improve on what I can offer @ronald: who knows?
The idea I had would have resulted in the search panel remaining on-screen at a place you specified but in testing it failed because of this: when the prompt is up on the screen, if you click away from it (to bring another window or app frontmost for example) the prompt disappears and doesn't return until you trigger the macro again. This is a feature of the Prompt for List action and I queried Peter about making it optional but he has no plans to do so.
All is not lost, however, as @noisneil has already written a macro that is the equivalent of Prompt with List and is called Prompt with List (HTML) that optionally will remain on-screen until deliberately dismissed. I am pretty sure that my idea plus Neil's macro can be made to achieve your requirement.
It's now too late for me to take this any further until after the holiday break so if you can wait I'll resume in a few days time.
Meanwhile Ronald, have a merry Christmas
Addendum:
Just FYI this is a description of what I did to your macro that came so very close to working!
The changes I've made to your macro are very simple as follows:
Engroup your two actions Prompt with List and $If Macro Group Active with an Execute Actions Until Conditions Met action (coloured teal in the screenshot)
Insert a Set Next Engine Window action before the Prompt with List action. This will allow you to specify where on your screen the search pane should sit.
Set the end condition for the Execute... group to be a variable condition that checks for Local__Result variable being empty.
(I can't add the screenshots as I'm not at my Mac.)
I will have a look at @noisneil 's macro and your explanations about your approach to this problem. I am very grateful that you put so much thought and work into it. Please take your time. Merry Christmas to you and your family ! thanks very much
Hi Ronald - I've managed to look at this and come up with a solution that uses @noisneil's Prompt with List (HTML) subroutine. The result is in this file:
It includes the macro you sent and Neil's subroutine, both with changes as follows:
Prompt with List (HTML) I've disable one action that processes the prompt dismissal which requires another subroutine/macro but is not needed in this case.
Your macro which I have modified wherever you see actions coloured teal.
Here is your modified macro showing the places I've made changes:
I fiddled around with the macro, making minor changes (location etc) and it is now absolutely perfect. You are a genius ! I encountered one minor issue which is that the pick from list prompt persists on the screen if I change app (Bear no longer at the front) instead of closing / hiding. I created a macro which clicks inside the search box followed by escape to close it manually which requires minimal effort.
I imagine that there is no simply way around this issue because it would require a Hazel type monitoring system which would react when the app is not at the front.
You are a genius, and you have invented a completely new kind of palette. There are no words to thank you enough !
Ah, yes - I missed that because I didn't fully realise what your workflow involves.
Tell me -
When you first sit down at your Mac and login (after just powering-up the computer) do you have a macro that runs all the apps you need for work, or do you just initiate then as needed?
When Bear (or Numbers, etc) is first run would this macro be triggered automatically or would you trigger it with your hotkey as and when required?
When you switch to Numbers, say, thus making Bear no longer the frontmost app should its search macro be replaced by the Numbers one, or would you expect to hotkey trigger the numbers one?
Sorry - this is getting a bit tedious (for the both of us)! What I'm really after is to get a feel for your workflow and your expectations while working with several of your preferred apps.
There may be a way around it, but it might not be simple depending on your expectations. I'd be happy to explore the possibilities for you if you wish but if you're satisfied with how things have turned out I'm happy for you
