Re: master 1e3b0f2: Improve doc strings of project.el

[Eli Zaretskii <eliz@gnu.org>]

> Cc: philip@warpmail.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sat, 20 Jun 2020 14:35:24 +0300
> 
> On 20.06.2020 13:07, Eli Zaretskii wrote:
> > In any case, my proposal was not about the API itself, it was more
> > about the implementation of the API.  For example, we could have an
> > implementation of the generic project-files API that consulted some
> > list instead of asking the VCS or the filesystem to provide the files.
> 
> You can of course do this already, in 10 lines or so.

I'm a user.  I don't want to write code every time I want something
simple from the project-related commands.  I expect such simple use
cases to be supported OOTB.

> But imagine you did add such a backend where project-files returns an 
> arbitrary list of files. And you use it.
> 
> How would project-switch-to-buffer consult it? Will it have to call 
> project-files now, as opposed to just using project-root as the basis 
> for comparison? And then compare buffer-file-name of all file-visiting 
> buffers against that list?

That's one possibility, yes.

> That would work for smaller projects, but in large ones project-files is 
> not instantaneous, so they will be penalized in performance by such an 
> approach.

We have faster data structures than lists.  We could use them.

And in any case, we should identify the needs first, and then
implement the features that support those needs.  Rejecting some of
the needs because they don't fit the current implementation is the
wrong way for designing features such as this, which is supposed to be
part of our IDE infrastructure.

> And project-switch-to-buffer should work with all kinds of projects.

Yes.  And one such kind is an ad-hoc collection of files and buffers,
where only the user knows which ones he/she is interested in and which
ones he/she isn't.  Every IDE I saw supports something like that, so
we should do that as well, IMO.

> That also wouldn't solve the problem of non-file-visiting buffers like 
> Grep from your example.

You talked about project-files, so buffers that don't visit files are
excluded, of course.  But an indication that supports marking buffers
as belonging to a project could support both file-visiting and non
file-visiting buffers.