[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: master 1e3b0f2: Improve doc strings of project.el
From: |
Eli Zaretskii |
Subject: |
Re: master 1e3b0f2: Improve doc strings of project.el |
Date: |
Sun, 28 Jun 2020 17:28:49 +0300 |
> Cc: theo@thornhill.no, philip@warpmail.net, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 28 Jun 2020 03:56:29 +0300
>
> 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"? 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 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)
. 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.
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...
- Re: master 1e3b0f2: Improve doc strings of project.el, (continued)
- RE: master 1e3b0f2: Improve doc strings of project.el, Drew Adams, 2020/06/20
- Re: master 1e3b0f2: Improve doc strings of project.el, Dmitry Gutov, 2020/06/20
- Re: master 1e3b0f2: Improve doc strings of project.el, Eli Zaretskii, 2020/06/21
- Re: master 1e3b0f2: Improve doc strings of project.el, Juri Linkov, 2020/06/21
- Re: master 1e3b0f2: Improve doc strings of project.el, Eli Zaretskii, 2020/06/21
- Re: master 1e3b0f2: Improve doc strings of project.el, Dmitry Gutov, 2020/06/27
- Re: master 1e3b0f2: Improve doc strings of project.el,
Eli Zaretskii <=
- Re: master 1e3b0f2: Improve doc strings of project.el, Dmitry Gutov, 2020/06/28
- Re: master 1e3b0f2: Improve doc strings of project.el, Eli Zaretskii, 2020/06/29
- Re: master 1e3b0f2: Improve doc strings of project.el, Stephen Leake, 2020/06/29
- Re: master 1e3b0f2: Improve doc strings of project.el, Juri Linkov, 2020/06/29
- Re: master 1e3b0f2: Improve doc strings of project.el, Dmitry Gutov, 2020/06/28
- Re: master 1e3b0f2: Improve doc strings of project.el, Eli Zaretskii, 2020/06/29
- Re: master 1e3b0f2: Improve doc strings of project.el, Dmitry Gutov, 2020/06/19
- Re: master 1e3b0f2: Improve doc strings of project.el, Eli Zaretskii, 2020/06/19
- Re: master 1e3b0f2: Improve doc strings of project.el, Dmitry Gutov, 2020/06/19
- Re: master 1e3b0f2: Improve doc strings of project.el, Eli Zaretskii, 2020/06/19