[TxMt] Re: Bundle support plist broken on Mojave (Philippe Huibonhoa)

Greg web at web.knobby.ws
Thu Jan 31 16:46:36 UTC 2019


Default is "ruby 2.3.7p456"
> 
> 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 at gmail.com>
> To: TextMate users <textmate at lists.macromates.com>
> Subject: [TxMt] Re: Bundle support plist broken on Mojave
> Message-ID:
> 	<CABF6MVzbki=T+-DZ18Sg1AmJA+K2Jw7=WoYHDG+buNo+H9jHOg at 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 at me.com> wrote:
> 
>> On 15 Dec 2018, at 09:13, Allan Odgaard <mailinglist at 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
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macromates.com/textmate/attachments/20190131/95e41be4/attachment.html>


More information about the textmate mailing list