[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: master 1e3b0f2: Improve doc strings of project.el
Date: Mon, 29 Jun 2020 01:35:19 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

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

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".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]