Re: OSX FSEvents file watching support

[Michael Albinus]

"Muir Manders" <address@hidden> writes:

> Hello

Hi Muir,

> I am interested in adding support in Emacs for Mac OS "FSEvents" file
> watching. FSEvents allows for efficient recursive directory watching,
> which would be a boon for packages like lsp-mode.

>From time to time there have been requests for an FSEvents backend of
filenotify.el. Until now, nobody has taken the ball. So it would be
appreciated if you could do this.

> I seem to have three options:
>
> 1. Write a new backend for filenotify.el. The existing backends
> explicitly don't support recursive watching, so I'm not sure if it
> makes sense to have one special backend that does support recursive
> watching.

An FSEvents backend even for the existing filenotify.el interface could
be a win. Additionally, one could think about extending the
filenotify.el functions to support recursivity. For the other backends,
this interface returns either kinda of "not implemented", or we mimic
the recursivity by an own implementation, traversing the directory in
question.

> 2. Publish a dynamic module that wraps the FSEvents API. It seems like
> most OSX distributions of Emacs have module support enabled, but I'm
> afraid there might be other challenges with this approach I don't know
> yet.

This would reduce the usability. Packages interested in recursive
watching would be limited to macOS. They might be less enthusiastic to
use this.

> 3. Publish an elisp package that calls out to an existing program that
> supports FSEvents like "fswatch". This approach probably has the least
> friction, but doesn't allow for tweaking FSEvents settings, and might
> have performance disadvantages.

This is still useful for watching remote directories via Tramp. Should
be implemented in addition to 1.

> Does anyone have any guidance on which approach makes the most sense,
> and in particular if a new recursive filenotify.el backend would be
> acceptable?

I would say yes, and yes. But let's see what other people say.

> Thanks,
> Muir

Best regards, Michael.