Subject: bug#21435: 25.0.50; file-notify has problems after renames

From: Eli Zaretskii <[email-masked]>
Date: Fri, 11 Sep 2015 15:32:36 +0300

> From: Tassilo Horn <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>,  [email-masked]
> Date: Fri, 11 Sep 2015 14:17:03 +0200
> 
> Michael Albinus <[email-masked]> writes:
> 
> > Thanks. Another point is whether we always can expect that all native
> > libraries will report exactly the same number of events, and then
> > whether they report them exactly in the same order (you expect
> > '(created changed deleted) here). Let's see how the test cases evolve,
> > maybe we need more tolerant tests.
> 
> Yes, I'm quite strict right now and IMHO in the current tests, that's
> the only sensible order of events.  But of course if it turns out that
> with some notification backend we can't achieve that guarantee, it'll be
> no problem to relax the assertions a bit.

I think if we ever find that the order is not guaranteed, we should
sort the events into the "right" order in filenotify.el.

Once again, the sole reason for having filenotify.el is to present a
unified API to applications, so that they don't need to know anything
about the back-ends and their idiosyncrasies.