[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#63870: 29.0.90; project.el can't dynamically populate the project li
From: |
Eli Zaretskii |
Subject: |
bug#63870: 29.0.90; project.el can't dynamically populate the project list |
Date: |
Wed, 28 Jun 2023 15:56:34 +0300 |
> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: 63870@debbugs.gnu.org
> Date: Wed, 28 Jun 2023 08:37:58 -0400
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Absolutely. I am trying to be careful about this: project-watch
> >> shouldn't create watches on VCS directories.
> >
> > But below you explicitly give an example where it will. And given the
> > fact that the majority of project.el projects use VCS as its backend,
> > I'd say we are already there...
>
> No: the watch on a directory is removed once the directory becomes a VCS
> directory.
No, AFAIU the watch is removed once there is a project in the
directory. But a VCS can work on a directory regardles of any project
creation.
> > Once again, this is dangerous; users could easily shoot themselves in
> > the foot, because not many are aware of the pitfall of using file
> > notifications for many directories. It makes no sense to warn against
> > something and at the same time let callers easily stumble upon that.
>
> I agree with that, I suppose. Personally I would be fine with a
> mandatory 1 or 2 levels of recursion, since I only need 2. Do you have
> a suggestion for what that interface could look like? It feels a bit
> awkward...
I'd actually begin by not providing even 1 level. Let the callers
call this new function explicitly for every directory which they want
watching. If someone ever complains that this is somehow inconvenient
(although I don't see why: directory-files is simple to use), then we
could consider extending the API.
But that's MO; please wait for Dmitry to chime in.