Bug Report: Local & Instance Variables Show in Variable token List
Observed Behavior
Both Local and Instance variables continue to show in the Variables Token List (Edit > Insert Variable) for an indefinite period, perhaps forever, with no way to be removed.
It makes no sense, and is in fact misleading, to show Local and Instance variables when editing a macro that has not created the variable.
This is completely inconsistent with the behavior of the KM > Preferences > Variables pane, which NEVER show either variable type.
It causes great pollution of the Variable list that might be used for selection, both from the menu and via auto-complete
I concur with every word. But I don't want the fix to stop there.
Viewing Local variables is impossible in the KM Editor, and I can understand why, because there's no correlation between the visible macro and any instance of the macro. However there is a cool way to provide the functionality to display Local variables. And that is to display it in the Debugger. The Debugger actually DOES correspond to an instance of a running macro. Here's how this could be resolved, with a new Action that looks like this:
I won't actually say this would be an easy fix, but that's exactly what I'm thinking.
This would actually really help me, because I find myself wanting to inspect Local variables. Because of the lack of inspection ability, I often find myself avoiding them until my code is perfected. And it's never perfected.
Thanks for pointing out that thread to me. Your point was the same as mine. I think the screenshot I posted above does add a little value to the discussion, so I think we should keep this thread for the record.
I do usually read the website's auto-generated guidance when it says "Your post is similar to these..." which is a wonderful feature but it doesn't always alert me to the right posts.
The variable insertion list includes all variables defined in any macro, so that they can be inserted. That is the purpose of the list.
It is “inconsistent” with the Variables preference pane because they serve two different purposes. One is to show and edit the global variables, the other is to assist in inserting variables into actions.
It is not “ pollution” of the auto-complete, it is the purpose of the auto-complete.
Showing only Local variables used within the macro would perhaps be sensible, except that it is common to use the same name for local variables in different macros (eg “Local Count” is likely to be used in multiple independent macros).
Restricting the Instance variables is impossible, since it is impossible (see “Halting Problem”) to determine which macros might be related to this macro in execution.
So I'm afraid I'm going to have to disagree with this one. This is working as designed and not planned to be changed.
Some way to exclude them might be possible, perhaps an overall way to replace the %Delete% token. But not any time soon.
I respect all your choices, Peter. But we are the community and sometimes we ask for things we can't get. We still love and respect you for all the great things you've done.
Really? How common is it? Do you have any actual statistics, or is this just a guess? Just because you use that pattern does not mean others do.
Even if Local/Instance names are reused, all the user would have to do is type it in the first time (like they would with any unique name), and then if you show only the variables used in the Macro being edited, they would be available.
For those that really do like to reuse the same Local/Instance names, it would be very easy to write a KM Macro to create, maintain, and choose variable names that are stored in a global KM variable. Of course, that could also be a built-in KM tool.
Impossible? That's a strong word. Maybe difficult for you to identify would be better. But then don't use of Instance variables require that the other macro be a sub-marco, called by an Execute Macro Action? So there's your link/method on which variables to show. And/Or, you could easily provide a means of indicating in sub-macros which calling macro(s) are to be referenced, for those who really want the Local/Instance variables available in a list/auto-complete.
Personally, I don't use the Variable Token LIst nor auto-complete because I find both to be more trouble than they are worth, since all variables from all macros are shown. So this bug does not really affect me personally.
OTOH, good source code editors that provide intelligent auto-complete of variable names within the code document being edited are very useful and helpful.
It will be interesting to see if there are any other KM users who join this thread to say they prefer to keep KM as it is.
Impossible is the correct word, since this is an instance of the Halting Problem, as I said.
Or parent macros. Or Execute Macros built by XML (which is an action that doesn't exist yet, but is planned).
But in any event, it is irrelevant, since the same point as Local variables applies - people reuse variable names, and inserting those variable names is the purpose of this facility. No, I have not done a statistical analysis of all the uploaded macros to verify whether individuals that upload different macros use the same variable names across different macros, but I would be highly surprised if that was not the case.
People can chime in if they like. It is unlikely to sway my opinion, since, as you know, I don't consider forum users to be particularly representative of all Keyboard Maestro users, and I don't base Keyboard Maestro design decisions on polls or votes. But if enough people feel strongly about it I might consider a preference for it, except that it would likely be quite a lot of work.
Awesome. That would be pretty useful to most of us noobs. Since you didn't say otherwise, I'm inferring that includes global, Local and Instance variables.
How about this; an action, called something like “Display Variables” that when inserted in the beginning of a macro, adds a new function to all the subsequent variable-creating or -modifying actions. That function is to append to a single, new window that automatically opens that has columns with the following titles;
• Variable
• Triggering Action
• Triggering Macro
• Value
and as any variable is created or modified, it gets a new line appended to this window.
So if MACRO1 creates variable ‘LocalA’, then var ‘LocalB, then ‘Instance1’ and then ‘Instance2’,
THEN it triggers a sub called MACRO2 which creates its own Local1 then Local2 then modifies Instance1 then modifies Instance2, by the end of the run the window would be displaying;
*Carried over from parent macro
———————————————————----------—
The editor could use the name of the action that set the variable to more closely define which action is being displayed in the list (i.e.: “Set ‘Local2’=“bbb”, {within 3rd IF’s THEN}”
Obviously this could be painstakingly created with a reoccurring Appending variable, but it would be nice to… not have to, and might appease a few folks
Hi @VDOCutter - the Checkpoint system I have released as a debugging aid for KM has features similar to this. You might want to compare it to your needs. (Apologies for off-topic post.)
Yes, there is a token with the list of set or used variables. Although not necessarily all the local values are available, since a macro at any given time does not necessarily have access to all local variables. The debugger does though, so it can display them.
If you want to compile statistics, add me to the list of users who routinely reuse variable names in different macros. "LocalIndex" in loops is just one example. Also, I fail to see how whittling down the Insert Variable By Name list by hitting a keystroke or two is such a huge pain. Removing variables from the list would be much worse. I'm glad you're leaving it as is.
