[Top][All Lists]

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

Re: A project-files implementation for Git projects

From: Dmitry Gutov
Subject: Re: A project-files implementation for Git projects
Date: Fri, 20 Sep 2019 16:28:07 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

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). That wouldn't be 100% reliable, though.

"Not feasible".  You are, in effect, saying that I have no real idea
what I'm talking about.  And that's exactly the issue at hand.

I suppose that's possible. And if so, my apologies.

FWIW, before you wrote that "giving up" message, I figured we've reached the same page, more or less. Maybe I lack reading comprehension.

Sorry, I can no longer afford discussions in which replies are posted
after two, sometimes 3 or 4 days,

Sorry about that.

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 if you see it as arguing, I see that as having to to explain stuff, sometimes multiple times, in different branches of this same thread.

Maybe you would prefer different levels of nesting, but they make reading things harder on my end, including when I also go back to re-read the messages in this discussion. I can try cutting out less context next time, but by how much?

with context stripped so thoroughly that I need to go back 2, 3,
sometimes even 4 messages back to even begin to understand how we
arrived to that.  You never even _try_ to compromise, let alone see
the issue from my POV.

I'm sorry, I don't know what you're talking about here.

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.

reply via email to

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