The repo is in a bit of a mess. People (myself included, sorry) have been sending in pull requests only for the editor they use. As a result, Textmate/Sparkup.tmbundle/Support/sparkup.py and vim/ftplugin/html/sparkup.py are two different files.
Are they meant to be the same file? If so they should both be symlinked to a main sparkup.py file in the root of the repo. Git handles symlinks just fine. That way, pull requests and edits would just go to the sparkup.py file in the root of the repo.
I know Vundle in vim handles this fine, but is there a particular reason you did not symlink the files?
Of course if there is a reason not to you could always add a CONTRIBUTING file in the root of the repo that says "please ensure you make changes to both files" and Github would show this to pull requesters.
Thanks for your work on Sparkup.
This is a good idea - would you be able to do it and submit a PR?
Here you go: #80.
Thanks for attacking this.
However, "Git handles symlinks just fine" is not true for Windows.
For the Vim plugin, the symlink is not really necessary (or will not work properly), since the plugin looks in the &runtimepath for sparkup.py. If installed via Pathogen/Vundle/.. it will only look for the original file.
But if the user copies the ftplugin directory (like mentioned in the README), he will have a dangling symlink copied (and sparkup.py will not be found).
Additionally, the Makefile (which is used to build the distribution zip files (probably not used anymore)) copies the sparkup.py file to those locations, and will currently probably fail to work probably (the cp will follow the symlink and would overwrite the file itself).
This should get addressed somehow, but I do not how to do this best.
Maybe @MarcWeber has a good suggestion, when he starts rebasing his changes (at https://github.com/MarcWeber/sparkup/tree/master/vim).. :)
The Makefile/build could be fixed by using a separate directory, but then there is still the problem with symlinks on Windows (at least).
OK. So Windows would have problems. This leaves the repo in a state again because it will again have to maintain multiple copies of the sparkup.py file. The best option I can see as yet then is the last one I mentioned in the original post - have a CONTRIBUTING file in the root of the repo and ask pull requesters to make sure they have updated both copies of the sparkup.py file. Again, that's messy, and not ideal.
I've addressed this by writing github.com/MarcWeber/vim-addon-manager which allows plugins to set a different runtimepath. I'll soon have time to merge all the changes.