Today's Topics:
1. Re: Bundle support plist broken on Mojave (Philippe Huibonhoa)
----------------------------------------------------------------------
Message: 1
Date: Wed, 30 Jan 2019 20:54:44 -0800
From: Philippe Huibonhoa <
phuibonhoa@gmail.com>
To: TextMate users <
textmate@lists.macromates.com>
Subject: [TxMt] Re: Bundle support plist broken on Mojave
Message-ID:
<
CABF6MVzbki=T+-DZ18Sg1AmJA+K2Jw7=WoYHDG+buNo+H9jHOg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Does Mojave still have Ruby 1.8 available? I have bundle files
referencing /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby
but that directory does not exist. I'm not sure how to proceed, since this
does break some functionality.
On Sat, Dec 15, 2018 at 12:29 AM Jacob Carlborg <
doob@me.com> wrote:
On 15 Dec 2018, at 09:13, Allan Odgaard <mailinglist@textmate.org> wrote:
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 [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.
[1] https://github.com/jacob-carlborg/GitLab.tmbundle/tree/master/Support
--
/Jacob Carlborg