GNU bug report logs - #21435
25.0.50; file-notify has problems after renames

Previous Next

Full log

Message #77 received at 21435 <at> debbugs.gnu.org (full text, mbox):

From: Tassilo Horn <tsdh <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 21435 <at> debbugs.gnu.org
Subject: Re: bug#21435: 25.0.50; file-notify has problems after renames
Date: Thu, 10 Sep 2015 21:22:02 +0200

Michael Albinus <michael.albinus <at> gmx.de> writes:

>> I've added a new macro to the tests now which lets you do things this
>> way:
>>
>>         ;; Check creation, change, and deletion.
>>         (file-notify--test-with-events
>>             3 3 (lambda (events)
>>                   (should (equal '(created changed deleted)
>>                                  (mapcar #'cadr events))))
>>           (write-region
>>            "any text" nil file-notify--test-tmpfile nil 'no-message)
>>           (delete-file file-notify--test-tmpfile))
>>
>> This means we're waiting for 3 events for at most 3 seconds, and then
>> apply the lambda to the received events.  The rest is the code which
>> causes the events to be emitted.
>
> That's good, yes. Please add a docstring to that macro (boring, I
> know, but it will help other people like Eli and me).

Done.

> One point: you don't call any longer `read-event'.  I believe it still
> makes sense; IIRC I did it because sometimes you must trigger Emacs to
> check all its file descriptors for new events.

I still do.  That macro uses `file-notify--wait-for-events' to wait
until all N events have arrived before calling the ASSERT-FN.

>> Another thing: the remote tests, especially the test03-autorevert
>> one, take really, really long (maybe 30 seconds).  I saw that this
>> uses some mock TRAMP method which suggests it is a mockup connection
>> which can probably simulate a fast or a slow connection.  If so, I'd
>> prefer to have a reasonably fast one so that I don't try to avoid
>> running all tests frequently.
>
> Well, the mockup method is a silly one and it even doesn't require a
> remote connection, so it shall be faster than any other Tramp method.
> And I do not experience serious delays when testing.

Hm, then I wonder what causes these extreme delays here.  The remote
autorevert test really takes at least 20 seconds here.  But I have no
issues using TRAMP with its ssh method for accessing really remote
files...

> You could alway skip all the remote tests.

As your tester, I obviously want to run all tests. :-)

Bye,
Tassilo

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.