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

[Dmitry Gutov <dgutov@yandex.ru>]

On 06.06.2020 14:53, Theodor Thornhill wrote:
> 
> 
> On Sat, Jun 6, 2020 at 13:15, Dmitry Gutov <dgutov@yandex.ru 
> <mailto:dgutov@yandex.ru>> wrote:
>> > Unless you make sure it's full-featured, indeed. But the problem might
>> become more severe in the future if we add more capabilities to projects.
> This would essentially mean that at least until the api is completely 
> stable the git version is the de facto implementation?

It's the "official" one, but, for instance, Projectile which we already 
mentioned before, could hook into the API and provide the same level of 
performance.

As far as future features go, it could be a concern, but can be 
addressed as the features appear.

The crucial point is, though, that "lightweight" project backends are 
probably not a good idea.

> How about as you proposed extract the vc until, then compose different 
> versions? Most projects will use it anyways, and my foo-mode shouldn’t 
> have miss out.

Not sure what you're saying here.

> I mean, if we want to support “.project”, I assume we still want to use 
> vc backend after we do git init. Should we have to delete that said file 
> then?

I think the "simple" backend, if added, would go after the VC one in 
project-find-functions. So doing 'git init' would automatically switch 
over, with all the accompanying consequences.

> What if we accept some pattern, then merge all the other 
> functions? I believe we can’t use generics, call-next-method and friends 
> for this?

Could you elaborate?

>> > arbitrary project can have a totally different set of ignores. So, at
>> the very least, I'm in doubt how to write the docstring.
>>
> An arbitrary project can then just add a “list file“ functions, and if 
> git is not there, it will just return nil

How does that address the question of ignores?