bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tassilo Horn
Subject: bug#21435: 25.0.50; file-notify has problems after renames
Date: Thu, 10 Sep 2015 21:22:02 +0200
User-agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux)

Michael Albinus <michael.albinus@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]