“Local X” will be passed to the shell script in the KMVAR_Local_X environment variable.
“LocalX” (which would also be a local variable) would be passed to the shell script as KMVAR_LocalX.
You’re right, none of those things are likely to happen natively in Keyboard Maestro.
However you can effectively do it yourself, just have a macro that runs on Engine Start (functionally equivalent to Engine Stop really), or at 4:00 every morning (assuming your Mac is always awake) or on the first Wake of the day (which requires a bit of mucking around to track the value of the DAY() function, but has been discussed elsewhere on the forum I believe), and have that macro delete whatever variables you feel are appropriate to delete.
Thanks for the answers. I didn’t realize or even conceive of the idea that “LocalX” would work. And I didn’t guess that KMVAR_Local_X would work for passing data to a shell. You are one of the people I admire most in the world, considering this great product you wrote and how you keep it maintained. Can the community contribute to a life insurance policy for you to ensure that someone maintains the product forever?
Regarding different types of variable lifetimes, if you are leaving it to us to assume the responsibility to delete variables at the end of day, or when system reboots, etc, then maybe to be consistent there shouldn’t be local variables at all because we could just as easily delete them at the end of the macro. I presume user demand convinced you to implement local variables, and similarly user demand could convince you to implement some of the other ideas.
These are covered in the wiki help, which you can get to directly from the Execute a Shell Script action by clicking the Gear menu and selecting Help.
User suggestions lead to lots of things being implemented (indeed, most things that are implemented are user suggested (or possibly caused by me as a user)). But I doubt any of the suggestions you made would be implemented, in part because the need to delete variables has been reduced with the addition of Local/Instance variables.
In some other universe, variables would have been local by default, and Global and Instance variables would have been the ones with names, but we don't live in that universe, and it's unlikely we can get there from here.
Sorry for bumping the old thread, but I have a question regarding Local variables and since there is already a topic about them...
As it says in the wiki: Local Variables ... Auto-deleted when Macro terminates
But when I open Select Variable drop-down I see a bunch of Local variables that are still present in the list.
I tried to re-run one macro with a Local variable but this variable is still present in the list even after macro is run.
Is there a way to get rid of these Local variables?
You can see a list of all persistent variables and their values (i.e. variables that are global, but not Local or Instance) by using Keyboard Maestro>Preferences and clicking the Variables tab. These variables "hang around" in KM and are not deleted automatically.
Personally I'd truly love the idea of having short form local and instance variables prefixes. And I wonder if it could be worth bringing up again this subject of possibly finding well suited successors to the short lived short form 𝕃ocal and 𝕀nstance variable prefixes?
Short forms prefixes would of course be especially beneficial for the local-prefix that have now pretty much become the default variable form for most KM users. And in addition to prevent finger fatigue (I can imagine most of us probably types the local-prefix tens of times a day on average), it would also be greatly beneficial in saving visual real estate in the editors user interface.
As the discussion in this thread have already proven it is not a simple task though, finding the perfect pair of these short form prefixes. But personally I'd rather take any implementation of short forms here, over having none on the account of not finding the perfect pair.
However prefixes would of course not here be chosen at random, and the way I see it there are at least six different concerns – from a user perspective, (from a developer’s I am sure there are many more) – that could be taken into account here:
Non-word-breaking — The ability to select the full variable name by double clicking seems very important to me
Typability — Especially important for the local variables, as it is so very frequently used. This one could be worked around by using a text expander (typed string replacement) though.
Sufficiently strong, but balanced, visual cue — It should be readable at a glance, immediately discernible if it is local, instance or neither. But it should not be too dominant either, as the actual individual variable name should take precedence over the prefix.
Rememberability — Related to the above, but maybe not as important(?), as we’ll anyways have the very rememberable local and instance long form prefixes, and I suspect the short form would very quickly stick to our memory whatever it would end up becoming
Slim or no chance of interference with existing global variable names — Of course very important, or else lots of old macros could break.
Compatibility with relevant scripting languages executed within KM — i.e. kmvar.ı_myVar needs to work in the same way kmvar.local_myVar does
ı and Î
With these concerns in mind, my first proposition would be "ı" ("ı_myVar") for local, and "Î" ("Î_myVar") for instance, (⇧⌥B and ⇧⌥D respectively, on a US keyboard).
They’re non-word breaking, and directly typable on many different languages Mac-keyboards. The reason for these being my favourites is that they’re visual clear/distinguishable, without them being dominating in text fields. This pair might not be perfect in the rememberability category though, as the symbol for local
"ı", all though visually resembling a lowercase L, would in actuality be a dotless lowercase I. However I think it is kind of countered by the fact that the Î so very strongly connotates as the i of the two. The up-arrow also kind of makes sense for me, as instance variables works in macros of more than one level.
ø and æ
My second choice would be "ø" ("ø_myVar") for local, and "æ" ("æ_myVar") for instance (⌥O and ⌥’ respectively, on a US keyboard).
As the above they’re both non-word breaking and directly typable on many different languages keyboards. Also by thinking of them as løkal and instænce they’re actually quite rememberable.
Here at the end of my post, after having presented my thoughts and ideas, I again want to stress that would be thrilled by any implementation of short form variable prefixes, and I would love to hear other ideas or thought about this subject. Also of corse to hear your thoughts, @peternlewis, and if you still now think it could be a good idea to implement short form prefixes for the local and instance variables
I understand, just wanted to ask — and it is not like short forms here would add any additional functionality so I am all happy with how local and instance variables are implemented as is!
To think that it was a time before these implementations that is now such an integral component of KM! Feels almost strange now for someone that first came on board with KM10. Very grateful for all the amazing features that have been added over the years!
@peternlewis, To me this is a usability issue, and it seems that any usability issue should always be worth reconsidering, even though one available solution was decided and implemented 7 years ago.
I have no problem typing the Local prefix, it has become second nature. Where I do have a problem is easily recognizing variable names, and managing expressions so long that they line wrap, sometimes more than once. I would consider a single character (maybe 2) a godsend.
