<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 15 Dec 2018, at 09:13, Allan Odgaard <<a href="mailto:mailinglist@textmate.org" class="">mailinglist@textmate.org</a>> wrote:</div><div class=""> <meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8" class=""> <div class=""> <div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">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.</p><p dir="auto" class="">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.</p></div></div></div></div></blockquote>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.<br class=""><blockquote type="cite" class=""><div class=""><div class=""><div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">My advice: If you want to use ruby 2.x for your custom commands, don’t use the support code.</p></div></div></div></div></blockquote>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.</div><div><br class=""></div><div>In this case I see now that TextMate.detach is simple enough to copy to the bundle and remove the dependency on TextMate::UI.<br class=""><blockquote type="cite" class=""><div class=""><div class=""><div style="font-family:sans-serif" class=""><div style="white-space:normal" class=""><p dir="auto" class="">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.</p></div></div></div></div></blockquote></div><div class="">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 [1] 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.</div><div class=""><br class=""></div><div class="">[1] <a href="https://github.com/jacob-carlborg/GitLab.tmbundle/tree/master/Support" class="">https://github.com/jacob-carlborg/GitLab.tmbundle/tree/master/Support</a></div><br class=""><div class=""> <div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">-- <br class="">/Jacob Carlborg</div> </div> <br class=""></body></html>