bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project

[Dmitry Gutov]

On 07.10.2021 10:17, Juri Linkov wrote:
> > > Maybe a better name would be 'project-directory-ignores'
> > > with the directory-based backend name 'project-directory'?
> >
> > I don't know if it's better. What does "directory" mean? Every backend,
> > every project has directories.
>
> Then maybe the backend could be named 'project-file'
> since a special file defines the project root.

That's a little more meaningful, though too close to 'project-files'. 
'project-markered' or 'project-markerfile' would probably be less 
ambiguous. But... (*)

> > As mentioned previously, the other option I had considered was 'novc'. Then
> > the variable would be called project-novc-ignores.
>
> "novc" is the worst variant.  It's not obvious that it means
> "no-version-control", and also will make no sense when more backends
> will be added.

Might not be obvious, but when you know what 'vc' stands for, 'novc' 
should at least be a strong hint. And then you could reach for 
documentation.

But indeed it's very short and might make less sense if more backends 
are configured.

> Or no more backends are planned, and all other possible
> roots should be handled by the same fallback backend?  Or would it be
> possible that more backends could be added in project-find-functions
> after the file-based fallback backend?  Then the name "fallback"
> will make no sense if it will not be the last in project-find-functions.

I don't know about the case of adding more backends at the end of 
project-find-functions (are there any people who have done this?), but 
otherwise, 'fallback' is both an indication that the backend is at the 
end, and a strong hint to avoid moving it to the front.

Suppose somebody puts it before 'vc' to use if for a purpose we did not 
design it for: make sure that some subproject 'foo' in their monorepo is 
considered a separate project. 'foo/Makefile' exists, so they add 
"Makefile" to project-fallback-markers, and it kind of seems to work.

But! File listing performance becomes worse: we didn't optimize this 
backend for use inside of (e.g.) Git repositories, we don't take 
advantage of 'git ls-files'.

More than that, it doesn't honor the ignore instructions from 
.gitignore. Whereas, in a lot of cases, it would be helpful (and even 
necessary for good performance) to honor them. But on the other hand, 
why would a 'project-fallback', or 'project-file', or 
'project-markerfile', honor .gitignore contents? Semantically, that 
doesn't make much sense. And yet, I'd wager like a half of the users 
would implicitly expect it to do so, and another half -- would not. 
That's doesn't seem like a great design.

> > This is not a done deal, just what seems the most optimal to me at the
> > moment. But opinions welcome.
>
> Maybe it will help to choose a better name while thinking about
> more possible backends that could be added later.

(*) ...it doesn't seem compatible with being used in arbitrary order 
with arbitrary backends.

Perhaps, if we change our mind on the overall design later, we could 
create a new backend, with a different name and more complex 
implementation logic.