bug#21241: 25.0.50; gfilenotify doesn't indicate when limits are reached

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> Well, one thing we could do was preferring plain inotify over glib's
>> GFileMonitor when both are available.  On my GNU/Linux box both are
>> available and configure chose gfilenotify as the default.
>
> I wonder if we should revert our decision to prefer gfilenotify if
> available, and instead use it only if there's no other supported
> method.  It begins to sound more and more like gfilenotify is more
> trouble than it's worth.

You mean the other emacs-devel thread where it has been reported that
gfile notifications might get delayed up to 30 seconds?  I haven't seen
that issue here but if it can happen and gfilenotify doesn't provide
some clear benefit over plain inotify, I'd suggest to use the latter by
default when it's available.

Well, at least it seems that THIS issue is considered to be a bug also
by one glib developer so chances are good that it'll be fixed
eventually.  But of course it may take some time until a fixed version
is distributed to all users and until then users will have to learn the
hard way why notifications don't work [1].

Bye,
Tassilo

[1] I've been working on magit-filenotify.el which automatically
    refreshes the magit status buffer when something in the git
    repository changes, and at some point it just didn't work anymore
    (no notifications) for repositories I've started working on later
    while it still worked for those I've had opened earlier.  Well, that
    way I've at least learned about inotify limits and how to change
    them... :-)