GNU bug report logs - #26126
26.0.50; file-notify-rm-watch removes arbitrary watches

Previous Next

Package: emacs;

Reported by: Andreas Politz <politza <at> hochschule-trier.de>

Date: Thu, 16 Mar 2017 14:16:02 UTC

Severity: normal

Tags: fixed

Found in version 26.0.50

Fixed in version 26.1

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

Bug is archived. No further changes may be made.

Full log


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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26126 <at> debbugs.gnu.org, politza <at> hochschule-trier.de
Subject: Re: bug#26126: 26.0.50; file-notify-rm-watch removes arbitrary watches
Date: Wed, 22 Mar 2017 14:23:47 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

>> We've discussed this a while ago, main reason (IIRC) was to achieve
>> same behaviour for the different libraries.
>
> That discussion was about local notifications, where indeed the
> situation is like you describe.
>
> But Andreas asks about calling remote handlers, about which we by
> definition know much less.

Nope. We know exactly which remote handlers are called, and how they
behave. Do you expect other implementations of remote handlers? I don't,
because I'm not aware of other candidates but inotifywait and gvfs-monitor-dir.

> In that context, it might indeed make sense to pass the file, not its
> parent directory, because the handler can easily reconstruct the
> parent directory if that's what it needs.  By contrast, there's no way
> for the handler to intuit the file which was stripped.
>
> WDYT?

I still don't understand what's the difference between local and remote
events in your eyes. I've tried to implement remote handlers to behave
exactly like the local ones. That's the Tramp philosophy.

Best regards, Michael.




This bug report was last modified 8 years and 55 days ago.

Previous Next


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