Re: A project-files implementation for Git projects

[Eli Zaretskii]

> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Fri, 20 Sep 2019 16:28:07 +0300
> 
> On 20.09.2019 15:59, Eli Zaretskii wrote:
> 
> > No, it cannot, because the events are lost before they reach the
> > Emacs event queue.  Unless, that is, you mean by "handler" something
> > that is outside Emacs, in which case I see no way for Emacs to control
> > how such a "handler" behaves.
> 
> It could work by detecting a "congestion" before the event happens (by 
> seeing that events fire up very quickly, so the queue must fill up 
> soon).

What is "it" here?  If "it" is part of Emacs, then no, it cannot see
any congestion coming, and cannot know anything about the events
firing up quickly, because these events are reported by inotify, a
service running outside of Emacs.

And if "it" is inotify itself, then you should be talking about this
with its developers, which are not here.  And the same with other
similar services filenotify uses.

> > and in which each of my arguments,
> > no matter how minor, always gets contradicted with counter-arguments,
> 
> I've seen the same from your side.

And that makes it okay?

> I *cannot* compromise by removing reliance on 'find' because we'll need 
> it anyway. You complained about it for some reason, but also yourself 
> acknowledged that it will remain necessary in certain cases.
> 
> What else is there to compromise on? Implement the file listing using 
> Bzr and SVN as well? People are free to work on that, as long as no 
> functionality is lost in the end, meaning proper fallback to 'find' (I 
> suppose) when the tool can't support the necessary feature (extra 
> ignores or whitelist) that the user requested.

This just reiterates the same arguments.  I see no reason for another
round of the same stuff and the same results.