I’m working on a new RuboCop bundle. I want the linting to take place everytime a Ruby document is saved, with warnings then displayed in the gutter.
So I implemented a very simple command using `callback.document.did-save` and `TextMate::Executor.run`, and it works great so far. However, if I set the command to “Output: Discard”, TextMate’s UI seems to be blocked (no cursor movement or other editing possible) while the command is running.
Interestingly this does not happen with “Output: New Window”: In this case I can continue editing the document even while the command is still running.
Is this a bug? Or is there are workaround?
(Eventually the bundle will of course also include a command that shows RuboCop’s output. But I consider this too intrusive to run on every save.)
Stefan
On 06 Aug 2016, at 23:21, Stefan Daschek stefan@daschek.net wrote:
I’m working on a new RuboCop bundle. I want the linting to take place everytime a Ruby document is saved, with warnings then displayed in the gutter.
So I implemented a very simple command using `callback.document.did-save` and `TextMate::Executor.run`, and it works great so far. However, if I set the command to “Output: Discard”, TextMate’s UI seems to be blocked (no cursor movement or other editing possible) while the command is running.
Interestingly this does not happen with “Output: New Window”: In this case I can continue editing the document even while the command is still running.
Is this a bug? Or is there are workaround?
It’s intended behavior. The reason is that the command should not be able to run and possibly edit the document simultaneously while the user is editing the document.
The solution is to run the command in the background/daemonized. See this post for an example [1].
My I ask why you’re creating a new RuboCop bundle when this one [2] exists? You might also want to take a look at this pull request that adds a RuboCop formatter command to the Ruby bundle [3].
[1] http://lists.macromates.com/textmate/2016-May/039535.html [2] https://github.com/mrdougal/textmate2-rubocop [3] https://github.com/textmate/ruby.tmbundle/pull/99
— /Jacob Carlborg
Am 07.08.16 um 10:15 schrieb Jacob Carlborg:
On 06 Aug 2016, at 23:21, Stefan Daschek stefan@daschek.net wrote:
Interestingly this does not happen with “Output: New Window”: In this case I can continue editing the document even while the command is still running.
Is this a bug? Or is there are workaround?
It’s intended behavior. The reason is that the command should not be able to run and possibly edit the document simultaneously while the user is editing the document.
The solution is to run the command in the background/daemonized. See this post for an example [1].
Ah, makes sense! Thanks for the tip, seems to work great: https://github.com/noniq/RuboCop.tmbundle/commit/a9b789400ccc57892b7bc846a71...
My I ask why you’re creating a new RuboCop bundle when this one [2] exists?
I tried this bundle but it didn’t work for me. And after looking at its source I decided that it was way too much effort to bring it up to date: For example, it tries to run RuboCop directly (that is, via `Rubocop::CLI.new.run` [1]) from the command’s Ruby process – in my experience this does not work well with today’s usage of Bundler, Ruby version managers etc.
I think nowadays TextMate should run Ruby executables like RuboCop or RSpec [2] like this:
* If a binstub (e.g. `bin/rubocop`) is present, use it. * Otherwise, if a Gemfile is present and contains an appropriate entry, run the executable via `bundle exec …` * Otherwise fall back to simply running the executable, presuming it is somehow globally installed. (I just realized that I should add support for `TM_RUBOCOP` at this stage.)
Are there other / better ways of doing this?
[1]: And this no longer works with recent RuboCop versions at all since the module has been renamed to `RuboCop` about 2 years ago: https://github.com/bbatsov/rubocop/commit/ff167d8f202baf7a68955db0aaf0dc29af...
[2]: I changed the RSpec bundle to work like this already some time ago: https://github.com/rspec/rspec.tmbundle/commit/a81c3f9c7395d72616ddc82ce5963...
You might also want to take a look at this pull request that adds a RuboCop formatter command to the Ruby bundle [3].
Thanks for the pointer, will look into it! Adding RuboCop to the Ruby bundle could make sense. However, I have one small objection: Running something like RuboCop on every save is quite intrusive, thus it should be something you need to explicitly enable. So the question is: Is it easier for a user wanting to use RuboCop to customize the Ruby bundle, or to install the RuboCop bundle? Not sure about this. Maybe just a question of personal preference after all?
Stefan.
Am 07.08.16 um 11:33 schrieb Stefan Daschek:
I think nowadays TextMate should run Ruby executables like RuboCop or RSpec [2] like this:
- If a binstub (e.g. `bin/rubocop`) is present, use it.
- Otherwise, if a Gemfile is present and contains an appropriate
entry, run the executable via `bundle exec …`
- Otherwise fall back to simply running the executable, presuming it is
somehow globally installed. (I just realized that I should add support for `TM_RUBOCOP` at this stage.)
Having read through https://github.com/textmate/ruby.tmbundle/pull/99 I understand that this cery problem has been discussed there at length, too.
I think it would make sense for TextMate to provide an API for this, so I just created https://github.com/textmate/bundle-support.tmbundle/issues/20
Feedback welcome!
Stefan
I tried this bundle but it didn’t work for me. And after looking at its source I decided that it was way too much effort to bring it up to date: For example, it tries to run RuboCop directly (that is, via `Rubocop::CLI.new.run` [1]) from the command’s Ruby process – in my experience this does not work well with today’s usage of Bundler, Ruby version managers etc.
I think nowadays TextMate should run Ruby executables like RuboCop or RSpec [2] like this:
- If a binstub (e.g. `bin/rubocop`) is present, use it.
- Otherwise, if a Gemfile is present and contains an appropriate
entry, run the executable via `bundle exec …`
- Otherwise fall back to simply running the executable, presuming it is somehow globally installed. (I just realized that I should add support for `TM_RUBOCOP` at this stage.)
One advantage of loading in RuboCop, like the command is doing now, is that you don’t need to start an additional process for executing the RuboCop command.
Are there other / better ways of doing this?
[1]: And this no longer works with recent RuboCop versions at all since the module has been renamed to `RuboCop` about 2 years ago: https://github.com/bbatsov/rubocop/commit/ff167d8f202baf7a68955db0aaf0dc29af...
[2]: I changed the RSpec bundle to work like this already some time ago: https://github.com/rspec/rspec.tmbundle/commit/a81c3f9c7395d72616ddc82ce5963...
You need this PR [1], where I fixed the issue with `RuboCop` vs `Rubocop`, added support for RVM and Bundler. It seems like this bundle has been abandoned. But I would rather take over the project myself than that someone starts from scratch.
You might also want to take a look at this pull request that adds a RuboCop formatter command to the Ruby bundle [3].
Thanks for the pointer, will look into it! Adding RuboCop to the Ruby bundle could make sense. However, I have one small objection: Running something like RuboCop on every save is quite intrusive, thus it should be something you need to explicitly enable. So the question is: Is it easier for a user wanting to use RuboCop to customize the Ruby bundle, or to install the RuboCop bundle? Not sure about this. Maybe just a question of personal preference after all?
I’m not sure. That PR, for the Ruby bundle, is designed for code formatting. That is, running RuboCop with the autocorrect flag. It will not open the HTML view showing errors with links back to the source code. It just shows the result in a tooltip. But I agree that one should be careful about executing commands on save.
[1] https://github.com/mrdougal/textmate2-rubocop/pull/11
— /Jacob Carlborg
One advantage of loading in RuboCop, like the command is doing now, is that you don’t need to start an additional process for executing the RuboCop command.
Right, but for this to work the command needs to run with the correct Ruby version (maybe a project specfic one set via RVM and rbenv), and this version may not be compatible with TextMate’s Ruby API, meaning the command can’t use all the nice things like `TextMate::Executor`).
Also, for some cases (eg. running rspec in a Rails project using the Spring preloader) running the executable via a binstub (if present) is even more performant than requiring it directly in the command.
But I think this discussion belongs into https://github.com/textmate/bundle-support.tmbundle/issues/20 :-)
You need this PR [1], where I fixed the issue with `RuboCop` vs `Rubocop`, added support for RVM and Bundler. It seems like this bundle has been abandoned. But I would rather take over the project myself than that someone starts from scratch.
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 :-)
Right now, my bundle already does all I need in only 50 LOC [1]. Less code, less bug, less maintenance work. (I decided to use the “clang” format to show RuboCop output as this plays nicely with the parsing provided by `TextMate::Executor`, which converts source code locations to clickable links etc.)
[1]: https://github.com/noniq/RuboCop.tmbundle/blob/master/Support/lib/rubocop_ru...
Adding RuboCop to the Ruby bundle could make sense. However, I have one small objection: Running something like RuboCop on every save is quite intrusive, thus it should be something you need to explicitly enable. So the question is: Is it easier for a user wanting to use RuboCop to customize the Ruby bundle, or to install the RuboCop bundle? Not sure about this. Maybe just a question of personal preference after all?
I’m not sure. That PR, for the Ruby bundle, is designed for code formatting. That is, running RuboCop with the autocorrect flag. It will not open the HTML view showing errors with links back to the source code. It just shows the result in a tooltip. But I agree that one should be careful about executing commands on save.
I tend to prefer the solution with a dedicated bundle for running RuboCop anyway :) Only problem I’m having with this right now is the duplication of the “find and run the right rubycop executable” logic between the two bundles. That’s why I suggest a dedicated API for this.
Stefan.
On 7 Aug 2016, at 11:55, Stefan Daschek wrote:
Having read through https://github.com/textmate/ruby.tmbundle/pull/99 I understand that this cery problem has been discussed there at length, too.
I think it would make sense for TextMate to provide an API for this, so I just created https://github.com/textmate/bundle-support.tmbundle/issues/20
I think this belongs in the Ruby bundle and not Bundle Support. Other bundles can require the Ruby bundle if they want to use this API (which they likely would anyway, given that it’s about Ruby).
Am 07.08.16 um 16:22 schrieb Allan Odgaard:
On 7 Aug 2016, at 11:55, Stefan Daschek wrote:
Having read through https://github.com/textmate/ruby.tmbundle/pull/99 I understand that this cery problem has been discussed there at length, too.
I think it would make sense for TextMate to provide an API for this, so I just created https://github.com/textmate/bundle-support.tmbundle/issues/20
I think this belongs in the Ruby bundle and not Bundle Support. Other bundles can require the Ruby bundle if they want to use this API (which they likely would anyway, given that it’s about Ruby).
Good point. I just created https://github.com/textmate/ruby.tmbundle/issues/102 – would be happy to get some feedback on this before I give it a try!
Stefan.
On 07 Aug 2016, at 13:29, Stefan Daschek stefan@daschek.net wrote:
Right, but for this to work the command needs to run with the correct Ruby version (maybe a project specfic one set via RVM and rbenv), and this version may not be compatible with TextMate’s Ruby API, meaning the command can’t use all the nice things like `TextMate::Executor`).
Also, for some cases (eg. running rspec in a Rails project using the Spring preloader) running the executable via a binstub (if present) is even more performant than requiring it directly in the command.
But I think this discussion belongs into https://github.com/textmate/bundle-support.tmbundle/issues/20 :-)
That’s some good points.
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 tend to prefer the solution with a dedicated bundle for running RuboCop anyway :) Only problem I’m having with this right now is the duplication of the “find and run the right rubycop executable” logic between the two bundles. That’s why I suggest a dedicated API for this.
Make sense. There are two different use cases here. The PR for the Ruby bundle is about formatting Ruby code and one can argue that RuboCop is used for that is only an implementation detail and therefore is better suited in the Ruby bundle.
-- /Jacob Carlborg
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.
Stefan
hi, Textmate seems to be showing the update available icon even when no update is available.
t
On 7 Aug 2016, at 22:58, Tim Bates wrote:
Textmate seems to be showing the update available icon even when no update is available.
You mean the “software update” badge on the app icon?
An update was made available shortly before you wrote, so I think the “Install & Relaunch” dialog just got lost on your screen somewhere.
-
Allan Odgaard -
Jacob Carlborg -
Stefan Daschek -
Tim Bates