[TxMt] Re: UI blocked while running command with “Output: Discard”

Stefan Daschek stefan at daschek.net
Sun Aug 7 20:54:21 UTC 2016

Am 07.08.16 um 21:25 schrieb Jacob Carlborg:
>> Good point. On the other hand, this other bundle has not been included
>> in TextMate’s “official” bundle index so far (it can’t be installed from
>> Preferences → Bundles), so we could also try to freshly create the new
>> shiny ultimate RubCop bundle ourselves :-)
> Sure, but I think we should try avoid spreading ourself too thin.
> There’s already more than one RuboCop bundle. It’s always fun to create
> a new project, but it’s usually the last 10%, to take the project across
> the finish line ,that are the most time consuming and not the most fun part.

I absolutely agree. But I think we need to also consider a second factor 
when creating or changing bundles: Long term maintenance.

I have the feeling that there are quite a lot of outdated TextMate 
bundles out there (see for example those other RuboCop bundles). This is 
not a problem as long as they still work, but some (many?) of them don’t 
(again, see the RuboCop bundles).

So from my point of view bundles should be written with the idea of 
making long term maintenance as easy as possible. Even if this means to 
exclude some features that would be nice to have but are likely to break 
with future updates of external tools or TextMate itself.

Of course this is also the reasoning behind my idea to have TextMate 
provide an API for features like “running a Ruby executable”: These kind 
of features need to be actively maintained as technology is changing, so 
better keep the maintenance burden in a single centralized spot.

Having said all this, of course nothing speaks against taking over one 
of the existing RuboCop bundles (if their current owners agree) and 
changing according to this way. But I’m not sure if it’s worth the effort.


More information about the textmate mailing list