Content of added_paths, modified_paths seems unintuitive?

[cobyism]

Given the following script:

require 'listen'

puts "Listening..."
Listen.to('source') do |modified, added, removed|
  puts "Changed detected!"
  puts "> Modified: #{modified}"
  puts "> Added: #{added}"
end

and trivial example files file1.txt, file2.rb, and file3.py under a source directory, I run the script:

$ ruby script.rb
Listening...

And then edit file1.txt and see:

Changed detected!
> Modified: []
> Added: ["example/path/source/file1.txt", "example/path/source/file2.rb", "example/path/source/file3.py"]

And then edit file2.rb and see:

Changed detected!
> Modified: ["example/path/source/file1.txt", "example/path/source/file2.rb"]
> Added: []

And then edit file3.py and see:

Changed detected!
> Modified: ["example/path/source/file2.rb", "example/path/source/file3.py"]
> Added: []

I would have thought those three operations would simply cause the output to be:

Changed detected!
> Modified: ["example/path/source/file1.txt"]
> Added: []
Changed detected!
> Modified: ["example/path/source/file2.rb"]
> Added: []
Changed detected!
> Modified: ["example/path/source/file3.py"]
> Added: []

I can understand why the first modification might trigger all files in the listened-to directory to be "added" (though the files existed before the script was run, so they weren't really added), but for the second two actions I can't understand why the previously modified file is the first path returned in the array, followed by the file whose change really triggered the event.

Is this how it's supposed to function? If so, it seems like it might be a little unintuitive.

I'm on OSX 10.7.3, with Ruby 1.9.3p0 (2011-10-30 revision 33570).

[thibaudgg]

Hi Cobi,

You right it should work as you thought, the behavior you report is definitely not the good one.
I can't reproduce the 'Added' bug, but I can reproduce the problem with the multiple 'Modified' bug.
What version of Listen are you using?

@Maher4Ever do you have an insight about that one?

[cobyism]

Gemfile.lock says listen is version 0.4.1. Would you like me to put the example code above into a repo to try and reproduce elsewhere?

[thibaudgg]

Yeah please, it would be helpful!

[cobyism]

Alrighty, here's the example code in a repo with instructions for reproducing the issue, including a shell script for modifying the files in sequence. Furthermore, I can reproduce it in multiple versions of ruby—see the bottom of the example code repo's README for specifics.

[thibaudgg]

Awesome, thanks!

[thibaudgg]

Ok, I got the same output now. @Maher4Ever same for you?
We'll fix that!

[Maher4Ever]

First of all, let me thank you for this great bug report and for making that issue-repo. It is ideal :).
I tried your repo on Ubuntu and I only got the second issue (with file2.rb):

Changed detected!
> Modified: ["source/file1.txt"]
> Added: []
> Removed: []
Changed detected!
> Modified: ["source/file1.txt", "source/file2.rb"]
> Added: []
> Removed: []
Changed detected!
> Modified: ["source/file2.rb"]
> Added: []
> Removed: []
Changed detected!
> Modified: ["source/file3.py"]
> Added: []
> Removed: []

On mac on the other hand, I got the same output you reported in that repo. I'll investigate more.

[cobyism]

Odd! No worries—let me know if you want me to test out anything on my end :)

[rymai]

Same output for me, thanks @cobychapple for the awesome issue report!

[Maher4Ever]

Could you guys confirm if the fix works? I tested it on all supported systems and it did work.

[thibaudgg]

Works like a charm for me. 👍

[cobyism]

Confirmed as working at this end too. Thanks for the fix! Does this warrant bumping the version number and updating what's available on rubygems.org so that others receive this fix too without specifying the GitHub repo?

[thibaudgg]

Yeah, +1 for a little release!

[Maher4Ever]

Great, then listen 0.4.2 will be released at the end of the day :)

[Maher4Ever]

Listen v0.4.2 is ✨ released ✨

[rymai]

👍!

[cobyism]

Excellent—thanks all!