Skip to content

chore(watchers): Watcher shares single fs_event from Event, node watchers use unique path prefixed debounce context #1453

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 26, 2022

Conversation

alex-courtis
Copy link
Member

@alex-courtis alex-courtis commented Jul 24, 2022

Split Watcher into Watcher and Event.

Event owns the fs_event for an absolute path. Watcher:new always creates a new Watcher which may share an existing Event.

Node watchers use a unique context: absolute path + incremennting index

Example:

real
real/file
link1 -> real
sub/link2 -> real
  • One Event created for /path/to/real. Two node Watchers created: /path/to/real:1, /path/to/real:2.
  • Modify real/file: one event fires, two watchers fire.
  • Open sub: node watcher created /path/to/real:3
  • Modify real/file: one Event fires, three watchers fire.
  • Remove link1: node Watcher destroyed: /path/to/real:2
  • Modify real/file: one Event fires, two watchers fire.

All the refresh/draw events will now correctly occur for each affected link/directory, along with the associated git event. This extra git event could be optimised away, however the added complexity is not worth it for the rare cases in which this will actually occur.

end
end

return M.pathexts[ext:upper()]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related to the change, however this hurt my eyes and I could not help tidying it.


M.uid = M.uid + 1
return Watcher:new(absolute_path, callback, {
context = "explorer:watch:" .. absolute_path .. ":" .. M.uid,
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unique debouncer context added so that the real/link jobs do not clobber each other.

w:destroy()
end

for _, e in pairs(Event._events) do
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be necessary however it does not hurt.

end

function Watcher:start()
self._listener = function()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to call back to a member function like Watcher:on_event however it doesn't seem possible.

watcher:destroy()
log.line("watcher", "purge_watchers")

for _, w in ipairs(utils.array_shallow_clone(Watcher._watchers)) do
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure i understand why a shallow clone is needed here ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Watcher:destroy will remove self from Watcher._watchers. That confuses the iterator.

@kyazdani42
Copy link
Member

LGTM, i wonder if we should move the debouncing inside the watcher event listener to avoid repeating the logic everytime we want to introduce a new watcher. Maybe for a followup PR. Looks good to me, let's merge this.

@kyazdani42 kyazdani42 merged commit eff1db3 into master Jul 26, 2022
@kyazdani42 kyazdani42 deleted the chore/watcher-tidy-links branch July 26, 2022 08:44
@alex-courtis
Copy link
Member Author

alex-courtis commented Jul 31, 2022

LGTM, i wonder if we should move the debouncing inside the watcher event listener to avoid repeating the logic everytime we want to introduce a new watcher.

That makes sense: Watcher:new takes a debounce timeout argument and applies it to _listener.

Debounce would still be used "standalone" by diagnostics and anything else.

On my list.

Almo7aya pushed a commit to Almo7aya/nvim-tree.lua that referenced this pull request Oct 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants