On 15 Dec 2018, at 09:13, Allan Odgaard
The problem is that many bundle commands need ruby 1.8, so the bundle support code needs
to remain compatible with 1.8 as well.
This is support code has been written by a dozen different people over several years, I
have no plans of rewriting it all to be compatible with both ruby 1.8 and 2.x, which in
itself is not a fun excercise, not even sure we can make the plist extension compatible
with both versions of ruby without switching to a version written entirely in ruby.
Understandable. I’ve been wanting to completely re-implement the support code with
support for 2.0 now for a while. But I’ve never prioritized it.
My advice: If you want to use ruby 2.x for your custom
commands, don’t use the support code.
Yeah, in fact, most of my commands are written in Ruby 2.0 but one of them is
using Ruby 1.8 to be able to use the completion window.
In this case I see now that TextMate.detach is simple enough to copy to the bundle and
remove the dependency on TextMate::UI.
In retrospect we probably shouldn’t have made a
“shared support” directory, at least not without much much stricter discipline, as now we
have a ton of legacy stuff that is pretty difficult to get rid of, because we have no idea
about which third party bundles rely on it.
The support code, at least the Ruby code, could be implemented as a separate gem. Then it
could be versioned like any other gem. I have a bundle  where the whole Support
directory is organized as a Ruby gem. It uses Bundler and several gems as dependencies.
The gems are bundled directly in the Support directory and included in the Git repository.
This works out quite nicely.