Notifier Tmux: bg color -- save and restore tmux state

[rudicode]

Here is the work in progress pull request, as suggested by @netzpirat
I hope it's understandable.

[rudicode]

I'm not sure how to send the notifier options hash in the loops for Notifier#turn_on and Notifier#turn_off
Right now they don't send anything, but the methods I wrote in ::Tmux#turn_on and ::Tmux#turn_off, do accept a hash of options.

[rudicode]

I'm not sure how to send the notifier options hash in the loops for Notifier#turn_on and Notifier#turn_off
Right now they don't send anything, but the methods I wrote in ::Tmux#turn_on and ::Tmux#turn_off, do accept a hash of options.

[netzpirat]

That's a nice start!

Each notifier module has its own options, which are stored when the notification is added. So you can grab it from self.notifications:

# Turn notifications off.
#
def turn_off
  notifications.each do |notification|
    notifier = get_notifier_module(notification[:name])
    notifier.turn_off(notification[:options]) if notifier.respond_to?(:turn_off)
  end
  ENV['GUARD_NOTIFY'] = 'false'
end

[netzpirat]

That's a nice start!

Each notifier module has its own options, which are stored when the notification is added. So you can grab it from self.notifications:

# Turn notifications off.
#
def turn_off
  notifications.each do |notification|
    notifier = get_notifier_module(notification[:name])
    notifier.turn_off(notification[:options]) if notifier.respond_to?(:turn_off)
  end
  ENV['GUARD_NOTIFY'] = 'false'
end

[rudicode]

Ok more work on this.
Changed the logic on this slightly.
Tmux#save_tmux_state now saves the tmux state as it is shown by the tmux command

tmux show

Any options are saved into a hash @@tmux_state
Is this an appropriate way to save the info inside the module? It works, but is there a different solution?

Tmux#restore_tmux_state, loops through the saved options and sets them to what they were or un-sets the option which was created by the Tmux module.

I hope this helps

[rudicode]

Ok more work on this.
Changed the logic on this slightly.
Tmux#save_tmux_state now saves the tmux state as it is shown by the tmux command

tmux show

Any options are saved into a hash @@tmux_state
Is this an appropriate way to save the info inside the module? It works, but is there a different solution?

Tmux#restore_tmux_state, loops through the saved options and sets them to what they were or un-sets the option which was created by the Tmux module.

I hope this helps

[netzpirat]

Each notifier module extends itself

module GNTP
  extend self
end

which is basically the same as opening the eigenclass

module GNTP
  class << self
  end
end

You do not need to to have a class variable, a simple instance variable like @tmux_state is fine.

[netzpirat]

Each notifier module extends itself

module GNTP
  extend self
end

which is basically the same as opening the eigenclass

module GNTP
  class << self
  end
end

You do not need to to have a class variable, a simple instance variable like @tmux_state is fine.

[rudicode]

Thanks , I'll update the code to reflect that.

[rudicode]

Thanks , I'll update the code to reflect that.

[rudicode]

I need to write some specs for this.

[rudicode]

I need to write some specs for this.

[rudicode]

Ok I added specs for the save_tmux_state and restore_tmux_state, methods.
This is working good on my work and home machines. But I'd like to get some input from anybody using this. :-)

[rudicode]

Ok I added specs for the save_tmux_state and restore_tmux_state, methods.
This is working good on my work and home machines. But I'd like to get some input from anybody using this. :-)

[cpjolicoeur]

This is greatly needed for Tmux users has having our bg and fg settings overwritten completely outside of the guard processes is annoying at best.

[cpjolicoeur]

This is greatly needed for Tmux users has having our bg and fg settings overwritten completely outside of the guard processes is annoying at best.

[rudicode]

@cpjolicoeur would you mind testing my branch of guard. It's available here https://github.com/rudicode/guard/tree/tmux-bg-color

I'm using it in one of my projects now. But I put it in my gem file like this
gem 'guard', :git => "https://github.com/rudicode/guard.git", :branch => "tmux-bg-color"

but for some reason can only run it using:
bundle exec guard
I think it has something to do with bundler handling git repos.

Before running it for the first time make sure your tmux settings are they way you want them.
Anything displayed with tmux show will be saved and then restored on exit. Any extra settings made by the notifier will be unset.

[rudicode]

@cpjolicoeur would you mind testing my branch of guard. It's available here https://github.com/rudicode/guard/tree/tmux-bg-color

I'm using it in one of my projects now. But I put it in my gem file like this
gem 'guard', :git => "https://github.com/rudicode/guard.git", :branch => "tmux-bg-color"

but for some reason can only run it using:
bundle exec guard
I think it has something to do with bundler handling git repos.

Before running it for the first time make sure your tmux settings are they way you want them.
Anything displayed with tmux show will be saved and then restored on exit. Any extra settings made by the notifier will be unset.

[netzpirat]

In Guard we have all methods and constants documented, so we have superior API docs on rubydoc.info. The inline comment should be moved to the method comment. We also have always an empty comment line before the method:

# Quiets tmux output
#
def turn_on(options = { })

[netzpirat]

In Guard we have all methods and constants documented, so we have superior API docs on rubydoc.info. The inline comment should be moved to the method comment. We also have always an empty comment line before the method:

# Quiets tmux output
#
def turn_on(options = { })

[netzpirat]

In Guard we have all methods and constants documented, so we have superior API docs on rubydoc.info. The inline comment should be moved to the method comment. We also have always an empty comment line before the method:

# Quiets tmux output
#
def turn_on(options = { })

[netzpirat]

Same here.

[netzpirat]

Same here.

[netzpirat]

Same here.

[netzpirat]

The unnecessary space can be removed, but aligning them is fine.

[netzpirat]

The unnecessary space can be removed, but aligning them is fine.

[netzpirat]

The unnecessary space can be removed, but aligning them is fine.

[netzpirat]

This method can be replaced by a simple attribute accessor attr_accessor.

[netzpirat]

This method can be replaced by a simple attribute accessor attr_accessor.

[netzpirat]

This method can be replaced by a simple attribute accessor attr_accessor.

[rudicode]

Thanks for the feedback, I'll start on the changes.

[rudicode]

Thanks for the feedback, I'll start on the changes.

[netzpirat]

Can you also merge the upstream changes? Would be nice to have it also in the release at the end of the week.

[netzpirat]

Can you also merge the upstream changes? Would be nice to have it also in the release at the end of the week.

[rudicode]

Sure what would be the proper way to merge the upstream changes into my branch? I'm a little new to this, and don't want to make a mistake. Should I:
git fetch
git rebase upstream/master

[rudicode]

Sure what would be the proper way to merge the upstream changes into my branch? I'm a little new to this, and don't want to make a mistake. Should I:
git fetch
git rebase upstream/master

[rymai]

Yeah it should work, and then you could squash your commits into one using the following method: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

and force push the squashed commit.

[rymai]

Yeah it should work, and then you could squash your commits into one using the following method: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html

and force push the squashed commit.

[rudicode]

Having a small issue, on exit guard does not call ::Guard::Notifier.turn_off , I added it to lib\guard.rb
This works, but i don't think it's the appropriate place.
Any ideas?

[rudicode]

Having a small issue, on exit guard does not call ::Guard::Notifier.turn_off , I added it to lib\guard.rb
This works, but i don't think it's the appropriate place.
Any ideas?

[netzpirat]

I've merged it and made some refactoring:

The biggest change was to inline the save_tmux_state and restore_tmux_state directly into its correlating on/off methods, but extracted the internal state handling into a separate method reset_options_store. I also removed accessors to the internal state, which was only used for accessing within the specs. The idea of BDD (testing in general) is not to rely on internal state and only describe the behavior (input/output) of the system from the outside. You can see this good on the rewriting of the specs (because of the removed internal accessors).

The turn off of the notifier was fine, I just added the missing spec and the execution order when Guard stops.

All the rest is adding missing specs, documentation and code style changes (also from previous merges of other pull request).

Thanks a lot for this pull request!

[netzpirat]

I've merged it and made some refactoring:

The biggest change was to inline the save_tmux_state and restore_tmux_state directly into its correlating on/off methods, but extracted the internal state handling into a separate method reset_options_store. I also removed accessors to the internal state, which was only used for accessing within the specs. The idea of BDD (testing in general) is not to rely on internal state and only describe the behavior (input/output) of the system from the outside. You can see this good on the rewriting of the specs (because of the removed internal accessors).

The turn off of the notifier was fine, I just added the missing spec and the execution order when Guard stops.

All the rest is adding missing specs, documentation and code style changes (also from previous merges of other pull request).

Thanks a lot for this pull request!

[rudicode]

Wow lots of changes to grok, over the weekend. Thanks for the help along the way.

[rudicode]

Wow lots of changes to grok, over the weekend. Thanks for the help along the way.