From: Nikolay Kudryavtsev <nikolay.kudryavtsev@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>, Lars Ingebrigtsen <larsi@gnus.org>
Cc: Zhu Zihao <cjpeople2013@gmail.com>,
Theodor Thornhill <theo@thornhill.no>,
41572@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
Subject: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project
Date: Mon, 11 Oct 2021 21:05:57 +0300 [thread overview]
Message-ID: <f11b40c6-ec15-426b-d78c-f86085b4669d@gmail.com> (raw)
In-Reply-To: <a8681281-b33d-b1f1-a87d-92754b115b0e@yandex.ru>
> I didn't find a definite answer in the rest of the email, so I'll
> continue this thread here.
Lets restate the answer: VC should be available to the user regardless
of the current project backend. When it is so, you can use whatever
defaults you deem reasonable, with ignores being respected probably
being a good choice.
> So you want to add a new backend based on GTAGS which also lists files
> by calling 'global -P' or something.
> I want all of those capabilities to be reachable, but we also need to
> decide which project backends configuration is on by default.
The question of default project backends is pretty irrelevant here. I'm
not suggesting adding anything there. I'm just saying that when the user
adds something, it should not be reduced to the second class citizenship.
The reason I've jumped in against your patch in particular is because
that's what it does. It makes a distinction between the (possibly) full
fledged function backends and the inferior marker file backends, which
get their own little ghetto. While I believe that we should treat such
marker file backends as first class citizens that are equal to any other
backend.
> If the user wants to choose what to act on (whole project or current
> module), the information about modules needs to be discovered as a
> separate semantic unit.
I don't think so. We have two options:
1. Nestable projects. In this paradigm any project can have however many
other projects in each subdirectories. You can go from child project to
a parent project pretty easily. Going from parent project to child
projects is a little bit harder, but still possible. So I can
compile(use custom action on) the parent projects from a child one, or a
particular(or all) child projects from parent.
2. Project units. Not gonna use the word "module" here, because we've
already used it for a different thing in this discussion. So one project
can have 0 or more units. Units cannot exist outside of a project and
are in turn are not projects themselves. Except that they can completely
look like projects, in cases like Maven or Makefiles.
Option 1 is simpler because it has only 1 concept. Option 2 introduces a
second separate semantic unit, but I don't see any benefit from
introducing it.
> Only if you intend to use the 'tags tool' as a build tool, e.g. list
> the available tasks or invoke one (for example, to rebuild the index).
> Then said tags tool can be put into build-tools-functions, with
> appropriate implementations for 'list tasks' and 'run task'.
I don't like such over-engineering, due to conceptually assuming that
all projects are build tool projects, all actions being connected to 1
particular tool and each tool necessarily having multiple actions. I
believe all of this is better left to users and backend developers. With
just actions and maybe action groups, if we want them.
> Do we really want to ask everyone to use a separate set of commands to
> apply the 'ignores' config from the current VCS repo?
No? Separate commands is just another advantage of VC being always
there(if it's there). Maybe I'm maintaining a certain part of the
repository, be it a module or whatever, and that's why I'm treating that
part as a project, since that's the scope I normally care about. But
then I notice a buggy function and use those commands to look whether
anything else apart from my code uses it in the wider repo.
P.S. Sorry for the terrible amount of typing errors in my previous
letter, too much writing for me last week.
next prev parent reply other threads:[~2021-10-11 18:05 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-28 3:32 bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Zhu Zihao
2020-05-28 7:42 ` Philip K.
2020-05-28 11:20 ` Zihao Zhu
2020-05-28 12:24 ` Philip K.
2020-06-03 11:04 ` Basil L. Contovounesios
2020-05-28 11:27 ` Zhu Zihao
2020-05-28 12:35 ` Dmitry Gutov
2020-05-28 15:46 ` Zihao Zhu
2020-05-28 19:58 ` Dmitry Gutov
2020-05-29 4:34 ` Zihao Zhu
2020-05-29 7:11 ` Philip K.
2020-05-29 13:58 ` Dmitry Gutov
2020-06-02 23:40 ` Juri Linkov
2020-06-05 19:02 ` Dmitry Gutov
2020-06-05 19:22 ` Theodor Thornhill
2020-06-05 23:11 ` Dmitry Gutov
2020-06-06 8:48 ` Theodor Thornhill
2020-06-06 11:15 ` Dmitry Gutov
2020-06-06 11:53 ` Theodor Thornhill
2020-06-06 12:17 ` Dmitry Gutov
2020-06-06 13:37 ` Theodor Thornhill
2020-07-20 20:55 ` Dmitry Gutov
2020-10-01 3:11 ` Lars Ingebrigtsen
2021-09-25 23:13 ` Dmitry Gutov
2021-09-26 6:38 ` Lars Ingebrigtsen
2021-10-03 18:06 ` Juri Linkov
2021-10-05 2:03 ` Dmitry Gutov
2021-10-05 2:08 ` Dmitry Gutov
2021-10-05 6:52 ` Juri Linkov
2021-10-05 12:42 ` Dmitry Gutov
2021-10-05 16:32 ` Juri Linkov
2021-10-06 7:21 ` Juri Linkov
2021-10-06 16:29 ` Juri Linkov
2021-10-06 21:16 ` Dmitry Gutov
2021-10-06 21:13 ` Dmitry Gutov
2021-10-07 7:17 ` Juri Linkov
2021-10-07 13:41 ` Dmitry Gutov
2021-10-10 16:47 ` Juri Linkov
2021-10-11 0:40 ` Dmitry Gutov
2021-10-05 14:39 ` Nikolay Kudryavtsev
2021-10-05 15:03 ` Dmitry Gutov
2021-10-05 15:21 ` Nikolay Kudryavtsev
2021-10-05 16:56 ` Dmitry Gutov
2021-10-05 18:19 ` Nikolay Kudryavtsev
2021-10-06 0:11 ` Dmitry Gutov
2021-10-06 14:09 ` Nikolay Kudryavtsev
2021-10-07 2:27 ` Dmitry Gutov
2021-10-07 13:08 ` Nikolay Kudryavtsev
2021-10-08 2:12 ` Dmitry Gutov
2021-10-08 16:24 ` Nikolay Kudryavtsev
2021-10-11 1:57 ` Dmitry Gutov
2021-10-11 18:05 ` Nikolay Kudryavtsev [this message]
2021-10-17 2:48 ` Dmitry Gutov
2021-10-17 11:52 ` Nikolay Kudryavtsev
2021-09-26 0:22 ` Dmitry Gutov
2022-11-26 1:49 ` Dmitry Gutov
2022-11-26 7:47 ` Eli Zaretskii
2022-11-26 13:22 ` Dmitry Gutov
2022-11-26 14:27 ` Eli Zaretskii
2022-11-27 1:08 ` Dmitry Gutov
2022-11-27 6:46 ` Eli Zaretskii
2022-11-27 14:10 ` Dmitry Gutov
2022-11-27 14:27 ` Eli Zaretskii
2022-11-27 15:51 ` Dmitry Gutov
2022-11-27 16:43 ` Eli Zaretskii
2022-11-27 21:41 ` Dmitry Gutov
2022-11-28 11:58 ` Eli Zaretskii
2022-11-28 12:30 ` Dmitry Gutov
2022-11-28 13:22 ` Eli Zaretskii
2022-11-28 14:29 ` Dmitry Gutov
2022-11-28 14:49 ` Eli Zaretskii
2022-11-28 15:31 ` Dmitry Gutov
2022-11-28 16:51 ` Eli Zaretskii
2022-11-30 2:26 ` Dmitry Gutov
2022-11-30 13:29 ` Eli Zaretskii
2022-11-30 18:52 ` Dmitry Gutov
2022-11-30 20:32 ` Eli Zaretskii
2022-11-30 20:43 ` Dmitry Gutov
2022-12-01 2:19 ` Dmitry Gutov
2022-12-01 6:02 ` Eli Zaretskii
2022-12-01 15:08 ` Dmitry Gutov
2022-11-26 9:52 ` João Távora
2022-11-26 12:29 ` Dmitry Gutov
2022-11-26 19:23 ` João Távora
2022-11-27 16:09 ` Dmitry Gutov
2022-11-29 9:46 ` João Távora
2022-11-29 18:51 ` Dmitry Gutov
2022-11-29 22:06 ` João Távora
2022-11-30 0:10 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f11b40c6-ec15-426b-d78c-f86085b4669d@gmail.com \
--to=nikolay.kudryavtsev@gmail.com \
--cc=41572@debbugs.gnu.org \
--cc=cjpeople2013@gmail.com \
--cc=dgutov@yandex.ru \
--cc=juri@linkov.net \
--cc=larsi@gnus.org \
--cc=theo@thornhill.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.