Closed robeady closed 2 years ago
The way you integrated the script will have significant effects onto the embedded environment in SublimeText due to overriding sys.modules["sublime"]
, but I have something else in mind for this.
I intend to separat the actual functionality entirely (and submit it to pypi) and then just use its interface in Sublime Text. The functionality is largely independant anyway and most of the ST-specific stuff revolves around better and more verbose error formatting.
I'll need to add a dumper for the new .sublime-color-scheme
format anyway in the future. Fortunately the architecture allows for that pretty easily.
Thank you for the script regardless. This will probably be useful for that process.
Edit: Actually, since you use Python 3.6 syntax, the file will just fail to load and cause a SyntaxError on ST's console. So I guess it won't break stuff at least, but it's not the proper solution.
Just fixed the import business, that was a workaround before I removed the dependency of the converters on sublime (by passing in the shell argument from the outside)
Ah, is ST still on python 2? or just an older version of 3?
Obviously I don't want Sublime Text to even look at the command line script. Don't know if that's possible.
ST3 uses Python 3.3.
I would honestly just refactor the whole thing. Your script will work for the time, I suppose, but I'll do something about it eventually.
I have created a command line script to run the converter outside of Sublime,
csscheme.py
.I've also fixed a few things. I don't have Sublime Text, perhaps you can test whether it still functions correctly in Sublime? Is there in any harm in the script I have added being present or does it need to be moved elsewhere?
My motivation is wanting to develop vscode syntax themes (which must be in tmTheme format).
"Hidden" themes are not supported, I don't understand their purpose...