On 27 Oct 2009, at 01:52, Dru Kepple wrote:
[…] One thought I had would be to get the TM_BUNDLE_SUPPORT value, pop off the bundle name and replace it with the bundle name of the target, and get to the Ruby file I need. But then...wouldn't any TM_BUNDLE_SUPPORT values used in the other bundle's scripts evalulate to the wrong place?
It will be possible to mark either a bundle or command to require another bundle. That will give TM_«bundle»_SUPPORT_PATH in the environment, but I did not consider that the included functionality might expect TM_BUNDLE_SUPPORT to point to “current dir” — though I don’t think stuff in a bundle’s support folder would need to make a reference to this variable, all files should be available via relative paths.
So I would suggest that you do what you suggest, that is, simply “hardcode” knowledge about where that other bundle is (relative to the current), and in the future, TM will resolve the proper path for you, so you can take out the hardcoding.
Would it be better to find a place for such universally appealing ruby files outside of TextMate? Should I learn how to write plugins, and/or deposit code into the SUPPORT_PATH?
I think your bundle approach is the proper one. In fact, when bundle requirements will be introduced (2.0) we intend to move a lot of the things in the shared support folder into bundles that will then be required by their respective users.
As for invoking commands (rather than including shared library files) that is a way more complex problem to solve, and I don’t think this should become general functionality, though I do want to expose the commands to CLI apps, mainly so that commands can be used as regular filters (in a shell).