Same error.
But please notice this. Why are all of these macros being selected/edited while your macro is running:
Just to be sure, can you zip the files again and send them to me? I want to make absolutely sure, because the problem is truly strange, and I don't want to go down a rabbit trail if there's another explanation.
But please notice this. Why are all of these macros being selected/edited while your macro is running:
OK, here's a short explanation: I'm doing this so I can get the name of certain macros.
Why do I need to do this? Because of something that Peter does, which makes it impossible for me to determine the macro's name under certain circumstances (I've been in contact with Peter about this).
You can see the issue with your macros with names like "Activate Window Switcher", "Activate Clipboard Cut Switcher", etc.
If you'll look at those macros, you'll notice that the macro has the exact same name as the first action that it runs. What this results in is the fact the macro is actually stored without a name. And I don't have the information available to reconstruct the name - only Peter can do that in his code.
So, I have to position the editor to the macro, and copy the name from the Name text box.
If the macro completes without generating an error, it positions the editor back on the macro you were editing when it started.
Obviously, this is something I should put in the documentation, huh? 
The previous error is gone, and now the macro runs for some seconds. However I get other mismatches now. It seems that whole parts of macros are missing in the Reload file (6 occurrences).
Here is the diff: diff.txt.zip (2.5 KB)
(Missing lines are prefixed with “-”.)
Dan, I'm probably missing something here, but if the missing macro name is identical to the name of the first Action, why not just use the Action Name as the Macro name?
LOL. Ah, would that life were so easy. For a handful of Peter's actions, the name that is displayed in the editor is not available anywhere in the source.
Example:
Here's the Plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
<dict>
<key>Actions</key>
<array>
<dict>
<key>IsDisclosed</key>
<false/>
<key>MacroActionType</key>
<string>ClipboardHistorySwitcher</string>
</dict>
</array>
<key>CreationDate</key>
<real>476327082.54374099</real>
<key>ModificationDate</key>
<real>505476259.15360302</real>
<key>Triggers</key>
<array>
<dict>
<key>MacroTriggerType</key>
<string>StatusMenu</string>
</dict>
</array>
<key>UID</key>
<string>1338284B-62A4-4B88-BCC1-DF119C175ACC</string>
</dict>
</array>
</plist>
Nowhere in the plist is the phrase"Activate Clipboard History Switcher". Peter has some action-specific code that doesn't make its way to the plist.
So I had to resort to chicanery. 
Well, the good news is that I can reproduce the issue.
I’m going to take a break, and might not even get to this until tomorrow. But I’ll keep you all posted.
I can’t tell you how much I appreciate both of your help. Obviously I wouldn’t have found issues like this without it!
@Tom, @JMichaelTX - The issue with Jim’s macros is that he’s got macros with the same name, in the same group. I assume Tom’s issue is similar.
Obviously, you can’t have two files in the same folder with the same name, so I need to do something about this. I used to check for this, but I removed it when I thought I had a better solution:
My solution for this was to name the files with the name of the Macro (or Group) followed by the UUID. That solved the issue with duplicate file names.
But the problem with naming the files that way is that there’s a lot of “noise” in the names, and when you look at it in a Version Control GUI, it’s pretty ugly.
Here’s the question: What do you think I should I do in this situation? Before I tried adding the UUID to the end of the filename, I just told the user they couldn’t have duplicate macro names, and dropped them in the editor on one of the duplicates.
Personally, I don’t have an issue with that. I mean, do you really need to have macros with the same name?
What do you guys think?
It's not intentional, but obviously it happens when I am copying and modifying macros.
Exactly. I don't like that idea.
I'd be happy with a simple solution like this:
Rename the duplicates by appending [DUP #1] etc.
Pick the most recently edited macro as the primary macro.
If you want to go to more trouble, then you could ask the user:
- Skip the Dup
- Append " [DUP #1]" to Name
- Enter a new Name.
But for the Beta, to keep it simple, just append " [DUP #1]" etc.
That would also make it easy to search for dups.
Hey Dan,
Yeah, I fussed at him quite a bit about that some years ago when I was parsing the XML with System Events.
Unfortunately I wasn't able to convince him to alter his schema one iota.
I just ran Macro Repository Updater v0.1.2, and it failed in the read-back phase.
The diff was fairly sizable.
Suggestion:
Add an Expand Tilde in Path filter after the Set Variable to Text action for “macrep_repositoryFolderPath”.
I've dropped my archive here:
/Backups/Keyboard Maestro Repo/
But someone might prefer their home directory, and it's wise to allow for $HOME-dir notation.
The filter will fail silently if there's not a tilde.
-Chris
I already automatically expand a leading tilde in the path. Does it not work right for you? It does for me - it's what I use.
Including @JMichaelTX in this part:
By the way, rather than modifying the Updater macro with my repository path, I just have another macro that sets that variable, then it calls the Updater macro.
I don't want to modify the Updater macro with my own path, because I'll forget and post the macro that way.
@JMichaelTX, @ccstone - New version 0.1.3 should hopefully fix the issue of duplicate names. It was easiest to just not allow duplicate names, so that’s what it does for now. It drops you in the editor and tells you to fix the problem.
You should probably clear out your repository folder before running this new version.
Changing the names to add suffix numbers, or anything like that is problematic for technical reasons. I could handle it if needed, but I’d rather not waste time on an outlier condition like this. After all, having duplicate macro names isn’t a good idea anyway… 
Hm, I still get the same error, and the macro is not telling me to fix problems. (As far as I can tell I don’t have duplicate names, at least not related to the problematic parts.)
I have changed some things in my macro library since yesterday, but comparing the diff from yesterday with the one from now (0.1.3) tells me that the problematic parts are still the same. (Only line numbers have changed.)
Do you want me to PM you the new diff and/or the complete files?
Note: I’ve run the macro twice, and always deleting the contents of the target folder before.
OK, version 0.1.4 really will fix the issue this time. I tested the last fix, but I had a bug which just so happened not to manifest with the particular use-case I was testing.
Fingers crossed.
OK, now it has found two duplicate-name macros and pointed me to them (very nice!). I deleted them, but now I get still/again the same “mismatch” error message as before. However, only three mismatches this time.
The parts that are missing in the ReloadedXML have one thing in common: They start with <string>"$KMVAR which is the beginning of a shell script in the first and only action.
At that occasion I noticed that I have quite some macros whose name starts with a dot. Do I have to change these macro names or do you see any easy way to convert a leading dot to an underscore or whatever?
Note: the leading dot in the macro names was intentional.
Here is the current diff: diff_for_ver014.txt.zip (1.7 KB)
And one of those dot macros: gpacrc.kmmacros (1.8 KB)
Interesting. Yes, the issue is the leading “.”. I exclude files that start with “.” from my directory contents listing.
I guess I should only remove them if they’re hidden files. Let me see what I can do.
This is a good catch! Thanks!
Yes, you could also just leave the leading dot. The only drawback is that they are invisible in the Repo folder in the Finder, no? But no problem for Git, as far as I know.
So what happens if you name a Group .Git? If you’re using Git, that will conflict with Git’s repository folder.
I think a good solution would be for me to add a leading underscore to the folder/file name, if it starts with a period. So you’d end up with _.SomeMacro, or something like that.
The nice thing is, the name of the file or folder isn’t really relevant, as far as I’m concerned. I get the names of the groups and the macros from the contents of the .json files. The file/folder names are only relevant with respect to needing to be unique, and giving you some idea of what group or macro they contain, when you look at them in version control.
So what do you think about my adding a leading underscore to the name, if it starts with a period? Got any other ideas?
1 Like
And you shouldn’t name your files “.DS_Store” either 
.
No, what I meant, was, that Git in general works fine with dot files. (Not counting “reserved” file names.)
Anyway, _.SomeMacro is perfect! I don’t see any conflicts ATM. But, as said, it’s not a problem to rename those macros either. [1] So don’t waste much time on that. (Probably nobody else has macros with a leading dot in the name.)
[1] It’s just a group of macros where the macros are named according to the dot-config file they are supposed to open.
Too late. Already did it. Version 0.1.5 is up.
Let's see if we can actually run the macro all the way through!