Re: filenotify.el

["Rüdiger Sonderfeld" <ruediger@c-plusplus.de>]

One minor nitpick I forgot:  You should use two hyphens for functions which 
are not meant to be used by the user.  I guess this should also include `file-
notify--handle-event'.

It seems those symbols

* file-notify-callback
* file-notify-descriptors
* file-notify-event-file-name
* file-notify-event-file1-name
* file-notify-callback

should not be directly used by the user.

On Tuesday 25 June 2013 21:00:43 you wrote:
> Just to be sure. The different low-level packages are not fully
> compatible (event names differ, for example); it would be a nightmare
> for filenotify.el when the different packages compete under the hood.
>
> In general, it could be possible to apply several low-level file
> notification libraries in parallel. But this wouldn't bring additional
> features, so we should avoid this.
>
> (Out of curiosity, I let compete file monitoring for "/tmp" and
> "/ssh::/tmp" in parallel. Very funny.)

I agree with Stefan here.  I don't see a reason why Emacs couldn't be compiled 
with several filenotify APIs.  Both inotify and gfilenotify are available on 
the same system.  filenotify.el should of course only pick one.  But it 
shouldn't really be affected if there are more available.

> > Maybe we could set `file-notify-support' to the name of the low-level
> > feature.  This would provide an easy way to identify which one is
> > used.
> 
> Really? I don't see a serious difference between (featurep 'inotify) and
> (eq file-notify-support 'inotify)

This would of course only make sense if the support isn't exclusive.

> I believe, that the callback function needs special care from the
> callee. In `auto-revert-notify-handler', I wrap the sensitive code by
> `ignore-errors'. For example.

But this error couldn't be handled by `ignore-errors' because it happens 
before the callback is called.  Or am I misunderstanding you?

Regards
Rüdiger