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

[Dmitry Gutov]

On 28.06.2020 17:28, Eli Zaretskii wrote:

> > To sum up, what I saw here is mostly what I'm already used to anyway: a
> > project is basically a directory with some files in it (the set is
> > generally based on the principle of exclusion, but some subviews can be
> > based on inclusion/whitelist as well), and not an arbitrary set of files
> > from random places on disk.
> >
> > Not to discourage alternative workflows, but this is the concept we
> > should work on supporting well first.
>
> What do you mean "first"?

Meaning, I have to prioritize the tasks in my personal queue. And there 
are other features I should get to as well. I hope you'll like them 
either way.

> why cannot we support both the workflow you
> are familiar with and the other kind?  It isn't like adding such
> support is exceptionally hard, it just needs to find an alternative to
> making decisions based on the default-directory alone.
>
> And how is your summary above not a "discouragement"?

I think it's an objective summary. Because you said that not having this 
capability keeps Emacs at a severe disadvantage to other editors. So it 
was clearly a subject that required analysis.

On the other hand, I'm open to having another backend that works in a 
different way, and willing to provide guidance to anyone who wanted to 
write it. And to try to keep the API sufficiently un-opinionated that 
both kinds of backends can be used through it successfully, with 
workarounds kept to a minimum.

> > I should also note that these other editors have no concept of
> > "buffers", and thus no way to configure their inclusion of exclusion.
> > Thus, any entity that might correspond to our non-file-visiting buffers
> > (such as a search window, or a compilation output window) is likely
> > implicitly considered to just be part of the current project or
> > solution. Please feel free to correct me here.
>
> The problem I raised is twofold:
>
>   . non file-visiting buffers could have a default-directory outside of
>     the project's root, and still be relevant to the project (I
>     provided a couple of examples)

Buffers are unique to Emacs, so it's hard to take example from other 
editors. I have to ask, though.

The model that other editors use, and the one I'm assuming you do as 
well (guessing mostly due to how tags' UI works), is that you work only 
on one "project" (in your sense of the word) at a time.

Then, would I be correct to assume that if there exists a Grep buffer in 
the current session, then it mostly likely belongs to the current 
"project"? If so, would there be any particular advantage to using 
project-switch-to-buffer instead of plain switch-to-buffer?

>   . file-visiting buffers can live in the same directory, but belong to
>     different projects
>
> Thus, using default-directory as the sole or the main indicator of
> belonging to a project limits us in the use cases we can easily
> support.
>
> The examples I provided were in response to your request to show IDE
> capabilities to add existing files to an empty project, thereby
> creating a project from existing files and not from a directory.

To the best of my understanding, in most of those examples, the files 
were either copied into said directory as a result of that action, or, 
if they had already been inside, their status had changed from "other 
files" to "sources files". The only example that I understood things to 
be different with any certainty, was Visual Studio's "solutions".

> But I have said all this several times already, and at this point it
> sounds like whatever I say, whichever examples I show, you will still
> discard them and maintain that using default-directory is a good
> method, so it doesn't look like this discussion is going anywhere...

I never said that it's an ideal method. And I'm sure there can be 
problematic examples out there. But I wasn't convinced by the example 
you gave because the reason for why it was bad was based on your 
understanding on the word "project", and not on mine. Thus, it's hard 
for me to choose a good solution for the project backend which is based 
on my understanding of the word "project".