On 28.05.2020 18:46, Zihao Zhu wrote:
If I have a project.el based plugin, and I wanna use them in a
directory not under VC. Add an mark to force project.el work is
easier than modify the source of plugin or initialize VC system.
The problem with that, is that next time we'll get a report that these
projects are too slow. Or that people who added .emacs-project file in
the middle of a VC repository suddenly get significantly worse file
listing performance, without expecting it.
So we'd have to add caching to the file list, and then some
invalidation, probably. And I'm not a fan of having manual
invalidation commands.
That's why I'm wary of adding such a separate project type by default,
especially when the initial proposal doesn't add any of the advanced
features described above, or explains how they won't be necessary.
But opinions welcome.
And this can also be used as a side solution to use project.el in
unsupported VCed project in Emacs (AFAIK, P4(Perforce) is not
supported by vc.el).
Perhaps we could add Perforce support to project-vc instead?
There was a vc-p4 packages somewhere out there. But if it's entirely
dead, we could add such support to project--vc-list-files directly.
Or, better yet, release it as a project-p4 package on GNU ELPA.
That all depends, of course, on whether the p4 command line utility
also has the means to quickly list repository files and add ignores.
IMO, a plain project is like a transient project.
One difference is, nobody really expects much from "transient"
projects. And this type of project is only applied when the directory
is not covered by any other kind of project.