Re: A project-files implementation for Git projects

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 17 Sep 2019 15:55:55 +0300
> 
> On 17.09.2019 15:03, Eli Zaretskii wrote:
> 
> >> 'find' can handle an arbitrary list of ignores, including whitelisting
> >> entries (a feature which I've yet to add, but still).
> > 
> > So you are going to convert the likes of .gitignore to a long list of
> > 'find's -name arguments?  Instead of just using the tools that can do
> > this at a flip of a command-line argument?  Why?
> 
> First of all, it's already done and working.

I don't see how it is relevant.  My point is that having to work with
long 'find' command lines is unwieldy and inelegant.  A given VCS
repository can have many dozens of ignored files.

> Second, like I said, using Git for this purpose seems easy enough. 
> Others, less so.

I don't see how you arrived to the last conclusion.  AFAIU, Tassilo
presented code to deal with others as well.

> It's not intuitive that a user has to vc-register a file before it shows 
> up in 'project-find-file'.

We already established that we will show also non-registered files, so
this is a non-issue.

>  From what I see, it doesn't allow to "unignore" certain files 
> selectively, and I'm not sure if there's a way to apply additional 
> ignores except by doing it in Lisp.

What do you mean by "unignore"?  Which VCS backend allows you to do
that, and how?

> >> And the filenotify-based cache would do one job.
> > 
> > IME, filenotify doesn't scale well, so I won't recommend it for
> > non-toy projects in this context.
> 
> Even if we just listen to "create", "rename" and "delete" events?
> 
> Too bad. I imagine it has more to do with maturity of the package, then, 
> so maybe someday.

It isn't the problem of filenotify the package, it's a problem with
the OS features it uses: inotify, knotify, etc.  They all lose events
when there are a lot of file operations in a tree.  E.g., try using
Auto-revert-tail mode on a log file produced by building the Boost
library -- in the default mode, where it uses file notifications, it
simply chokes.

> > I think you are wrong here.  It is 'find' that needs to be coerced to
> > do a job that is not really its prime, and a project's view is in most
> > cases almost exactly that of the VCS used for the project.
> 
> It's a job we've been using 'find' for for decades, and I only had to 
> adapt some existing code.

That something _can_ be done a certain way doesn't yet mean it
_should_ be done that way.

> > The
> > difference is just-now added files that were not yet registered, and
> > how many of these can there be?
> 
> That's not the only problem. We want to change the ignores list 
> arbitrarily, or maybe just use a user-defined one. It will usually 
> correlate with the contents of gitignore/hgignore/bzrignore, but not 
> exactly. And neither Hg or Bzr seem to offer easy ways to adjust their 
> lists of ignores before output.

Then those features will be not available for hg and bzr, or we will
tell their users that must have that to switch to 'find'.  But let's
not bypass VC where it can do the job, because that's TRT from where I
stand.  We should not design our implementations for the lowest
denominator, especially when we know that a large proportion of the
users will use Git anyway.

Thanks.