Best way to track variables for debug?

I'm, finding it a bit tricky to debug a variable heavy macro. What I'd really like to see is a live spreadsheet of all the variables, so that I can understand what the situation is at any point more easily than having to shuffle through them in the preferences/variables.

I wondered about writing them to a text file, updating a spreadsheet etc.

Any suggestions? Does KM have such a feature (better for tracking than the prefs/var)? Has someone worked up something similar already they can share?

Hold on to your horses, I've just discovered the VALUE INSPECTOR

1 Like

Yep, it's a pretty good tool, but way too limited to be of much use to me:

  • It does NOT support Local and Instance Variables
    • I very rarely use global variables any more.
  • You have to build the list manually every time you need it, if being used for more than one macro at a time
  • We really need:
    • Support for Local and Instance Variables
    • Ability to save and restore sets of values
    • Automatic creation of list of variables like most every other Debug tool I have ever used.

If it is that complicated, this is my workflow

Even if a variable is local, declare and use it as say zzLocalvariable, so whilst testing it is global and then you strip out the zz when it is working

Define a separate sub macro that displays a window with ALL your variables
i.e. var1 = ....
var2 = ......
and then you can call your sub macro at ANY point in the main macro execution

Finally, you can export your macro to .kmacros format
Using Atom (free XML editor) you can do global search and replace e.g. to stip out leading zz
and to find mis-spellings.
You then just move it back into your kmlibrary


@jonathonl, I do most of that, but it is royal PITA, and big time waster.
KM is supposed to help us SAVE time, not WASTE time.

So I'll keep pushing for a better KM Debugger and Variable inspector until we get one. :wink:

BTW, you can't use Sub-Macros to display Local variables in the calling Macro.

1 Like

@jonathonl already knows that which is why he temporarily names his variables that will eventually be local with a “zz” in front of them.

You need an eye for detail in this job :wink:

1 Like

I've got one! Would you like to borrow it? :wink:

You can read his mind?

With respect to "detail", he does say "ALL" variables, which would include "Local"

Finally, I'm sure jonathon can speak for himself. He's not shy. :wink:

1 Like

It's always good to have a hobby…


ha ha ha.

I was taught perseverance from when I was a child, and then it was reinforced by several mentors in my career. Get used to it.

Maybe you can identify with this: "The squeaky wheel gets the oil".

But seriously, since you are a professional programmer who no doubt makes extensive use of professional debugging tools every day, how can you live with yourself giving us such a lame debugger? :wink:


I had an issue with email over the weekend and thought that my question hadn't had any action, but I looked back in and see it has.

Thanks for all the input and suggestions.

In my dreams I had imagined something like the Value Inspector, but which is easier to add variables to, which flashes up which ones have changed when they do, and has the facility to play back macros at slower speeds (25%, 50% whatever). I'm only a beginner and have run into debugging issues already. I realise I've got a lot to learn, perhaps I'm not being as efficient as I could be, but even so, better debugging tools would be very helpful.

Just to round things off, I am very grateful for input of my colleagues earlier, but JMichaelTX has a point that the debugger is one of the weakest aspects of Keyboard Maestro, and whilst it is probably not an issue for the casual user, it certainly is for the heavy user.

I will take this opportunity to point out several areas that could be fixed fairly easily...

a: personally, I prefer a variable to be declared then used rather than have a mis-spelling create a "new" variable. Maybe this could be a preference setting.

b: the ability to generate a xref for a macro or a "set of macros" or all enabled macros

c: predefined tag that could be attached to a comment so that certain comments could be extracted for documentation
1: purpose of macro
2: change log history
3: macro dependencies
4: top level comment etc
5: client or system or user

the tags could be added via the cogwheel i.e. under the bonnet

d: finally, the most surprising of all is the editor search is not a complete match
i.e. if you search for say LocalOne
it will effectively match LocalOne, LocalOneA, LocalOneZZZ etc
thsat the search is LocalOne*
why we cannot have Local??e* etc is beyond me.

That's easy - as a general rule, I do not use the debugger in my coding. I use Assertions and I code carefully and with minimum complexity to ensure I don't write code that needs to be debugged, and failing that I use “printf debugging” - basically logging of state to determine where things are wrong. I also run permanently with the same optimised compiler settings that I ship Keyboard Maestro with so that I am testing under the same conditions as my users are using, which means that for the most part, most variables are not displayed in the debugger. As such, I very rarely use the debugger in any meaningful way in my programming.

I get that, but folks here need to realise that they are highly unrepresentative of Keyboard Maestro users in genera - just being on this forum makes you highly unrepresentative. The vast majority of Keyboard Maestro users will never use the debugger. My time on its development has to reflect this fact.

No, that is no Keyboard Maestro. If you want a strict programming language, then that is fine, there are plenty around, but Keyboard Maestro is not a programming language in that sense. It is a scripting system, and that sort of structural requirement may be desirable to some, but it is not something that is likely every to come to Keyboard Maestro.

I don't even know what that means.

You can define your own tags and use them as you see fit, it is not something Keyboard Maestro is likely to define.

Maybe I would add named tags to macros, but problem not.

I don't know why that would be surprising, it is how most search works in my experience. Certainly typing this in to Safari, it's search behaves the same way. Same for Mail.

I'm sorry, and I know it is disappointing to some of you who are on the extreme of Keyboard Maestro users, folks with thousands of macros, massively complex macros, whole application systems, etc, but Keyboard Maestro is a scripting system that is designed for a large audience of users, and I am one person with limited resources, and those resources have to be spent appropriately. I also have a vision for where Keyboard Maestro sits as a scripting language in the continuum of programming languages, and Keyboard Maestro’s design needs to be consistent with that.

None of this is to say that there wont be continued development of the debugger, or of organisational facilities, or whatever. No doubt there will be. But also no doubt it will be less in that direction than some of you might wish.


I get around the problem by writing perfect macros from the start, so they never need debugging.

Wow! You really don't use the debugger of any IDE?
Have you ever used Script Debugger 7 ?
The debugger is totally awesome, and allows you to easily explore complex objects to see property names and values.
Plus, setting a debugger to break when a certain variable meets a certain criteria is extremely powerful.

Your technique is what Mark Alldritt calls "Caveman Debugging" LOL

I also find the Chrome JavaScript debugger to be excellent.

I agree that you need to focus on what most users need.
But I am somewhat surprised that "the vast majority of Keyboard Maestro users will never use the debugger".

Do you mean will never even try to use the debugger?

I would think that the fact KM uses Global Variables by default would mean that a lot of users would have "unexplained" error in their macros. I know you know the danger of using global variables in normal programming languages -- most, if not all, experienced, successful developers warn against using global variables.

My guess would be that if a typical user figures out first, that there is a debugger, and then how to invoke it, they have little clue as to how to use it. Since it does NOT display the full macro, like most debuggers display the full code, it is probably a mystery to most users.

OTOH, if the KM debugger could work like most debuggers, and be displayed when there is an error, showing the exact Action with the error and all of the other Macro Actions, and all of the data being using in that macro, it could be very helpful, IMO.

I totally get all that, and agree with and support it.

In fact, in my own list of KM requests, an enhanced debugger would be far from the top. :wink:

Still, if you could do one thing that would really greatly improve debugging, it would be at least allowing Local and Instance variables to be used in the Value Inspector.
Next would be displaying all variables used in a Macro automatically with the debugger.

I know you're busy, so you need not respond to my above comments about using debuggers in general.

Yes, showing Local/Instance variables, either in the Value Inspector, or in the Debugger is definitely on the todo list.


Just to offer my two cents: I use @DanThomas’s favorite action to create two actions and group them together:

  1. Show variables in window.
  2. Cancel macro.

I insert wherever I want and run the macro. Before running, of course I edit the show variable in window to show the variables I want to display, as many as I want.

The macro will run until it displays the variables in window and cancel the macro.

I found it is better than the debugger. Maybe it was because I was not familiar with it, with debugger I could either only do one step at a time, or run the macro to the end.

But by inserting the group I said above, I can make it go through the actions instantly, and show the variables I want to see, and cancel the macro right there.

Then I can cut the group and run the complete macro to test it. If the result is still not what I expected, I will paste the group to a later point of the macro and repeat the previous steps.


:+1:+1 That’s exactly what I do too. When I first started using KM I was doing a lot of UI automation and I found the built-in debugger didn’t play well with that situation which is why I resorted to the “display and quit” approach.