It seems like kmsync is currently saved as a binary plist. Would it be possible to save it as an xml plist so that I could see diffs when I keep my plist in git? Thanks!
Probably not, but you can see the diffs using BBEdit, and it has git support I believe.
I forgot to mention that plists have an xml format, so it seems like it should just be a matter of saving it as the xml format instead of the binary format. You can actually convert between the two with:
# to xml
plutil -convert xml1 Keyboard\ Maestro\ Macros.kmsync
# to binary
plutil -convert binary1 Keyboard\ Maestro\ Macros.kmsync
It seems rather unnecessary to save it as binary. Maybe it loads faster or something, but it prevents regular text diffing and catting.
For now, I have a kmsync-commit script, like this:
#!/usr/bin/env bash
if [ "$*" = "" ]; then
echo "Usage: $(basename $0) <commit message>"
exit 1
fi
cd ~/.dotfiles
cp extra/Keyboard\ Maestro\ Macros.{kmsync,xml}
plutil -convert xml1 extra/Keyboard\ Maestro\ Macros.xml
git add extra/Keyboard\ Maestro\ Macros.*
git commit -m "$*"
Binary plists are faster and smaller, and for most purposes equivalent, which is why they are used. As you note, you can convert them back and forth, or you can use tools that can deal with them explicitly (indeed, I do a daily diff of mine each morning in BBEdit to ensure I haven’t accidentally messed up the load/save code of some component.
I would think that both the speed and size difference for Keyboard Maestro would be negligible, yet it’d be more convenient for those of us who want to store them as plain text. I’m not sure I hear a compelling reason to store them in binary other than it’s the default? Maybe it could be an option?
You would be surprised - I have users with very large macro libraries (far larger than Keyboard Maestro was ever really designed for) for which the size difference is very significant.
In any event, diffs of the the sync or macro library files will not necessarily help you as the files contain arrays of groups and macros which are really sets and so the order of them is indeterminate - it happens that it has been consistent up to now, but that is an implementation detail that actually changed just the other day in my build of what will be 7.0. So diffing them would not work well in that case either.
Yes, I could add an option, but I do not like adding options unless I feel there is a compelling reason - every option adds complexity. Even the hidden ones adds code complexity.
I'm not compelled by this use case, you have a workaround of sorts already, and good tools will deal with the files whether they are binary or text regardless, and otherwise you can convert them to text as needed.
If other folks are desperately in need of this as well, they have never mentioned it to me. I'm happy to be corrected if this is something that is widely desired, but otherwise it's not something I'm likely to support even as an option I'm afraid.
Sorry I don't have a better answer for you.
No problem, thank you for the explanation and the great app
If other folks are desperately in need of this as well, they have never mentioned it to me. I'm happy to be corrected if this is something that is widely desired, but otherwise it's not something I'm likely to support even as an option I'm afraid.
@peternlewis I echo this request for a plaintext sync file.
Like the OP, I want to commit my KM macros via git and "sync" them via github.
After making a modification to my macros, I want to commit the text of that change to my git changelog. I want the text to be visible in git diffs, on github, in pull requests, etc.
There is no likelihood of a plain text format for any save files ever happening.
The current files are mostly XML files, generally binary formatted ones. If you want you can convert them to XML text versions, which is as plain text as they will ever likely get.
Future versions may well use different formats which are likely to get less text (such as SQLite files for example).
Export the macro (or use the kmsync file) and convert it to text XML - that is as good as it is going to get.