From: Dmitry Gutov <dgutov@yandex.ru>
To: "João Távora" <joaotavora@gmail.com>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
Danny Freeman <danny@dfreeman.email>,
Eric Abrahamsen <eric@ericabrahamsen.net>,
emacs-devel <emacs-devel@gnu.org>
Subject: Re: Subprojects in project.el
Date: Sat, 26 Nov 2022 04:05:43 +0200 [thread overview]
Message-ID: <79a17a5c-d1c1-ce69-d29a-9127150fb1d7@yandex.ru> (raw)
In-Reply-To: <87zgcesg8l.fsf@gmail.com>
On 26/11/22 02:37, João Távora wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>>>>> I can't understand what is discourteous about this.
>>>> That would be not following the procedure the maintainer has asked you
>>>> to follow.
>>> If that means silencing me on emacs-devel, then you're out of luck.
>>
>> Is that what you do when you ask somebody to use the bug tracker?
>
> I'll use the bug tracker when I think it's appropriate. Let's not
> insinuate I'm some kind of inconsiderate delinquent for not moving the
> discussion there as you would want. I'm not reporting a bug and I've
> politely declined your suggestion, so stop beating this horse.
Must be nice to be the person who gets to decide what is appropriate in
any situation.
>>>> I don't really know what "the user wants". People apparently find this
>>>> discussion too scary or meandering to provide any additional
>>>> input. The several who I asked to comment have walked away
>>>> perplexed. Or perhaps it's just Debbugs.
>>> People seem to be contributin a healthy amount of information here.
>>
>> Yes and no. Nobody has bothered to comment on the messages in the bug
>> report, or on the patches in it.
>
> If they help the discussion, suggest you put your patches in a scratch
> branch and announce it here. It's not much work for you, I suppose and
> personally I find it simpler than finding your patches and applying them
> to the right version.
I suggest people look at the patches where they are posted.
>> Note that it would also be possible to do through some other
>> means. E.g. using some command in Xref result buffer which would
>> filter by file names and hide the rest.
>
> *compilation* and *shell-command-output* are not in any kind of
> structured Xref mode where that hypothetical command would operate.
> Even if such a command could be devised, I don't find that don't find it
> a very good solution. If one knows the where to look in, it's better to
> grep only one haystack instead of the whole barn just to throw away most
> of the needles.
Sure.
>>> Not all files that belong to the super-project necessarily belong to a
>>> sub-project. Some of them _only_ belong to the super-project.n
>> Do the files that belong to a sub-project belong to the super-project?
>
> Yes: in my view they belong to both. i.e. if you project-find-file in
> the super-project, you can find a file in a subproject such that a
> subsequent project command operates on the subproject.
Okay, good.
>>> Anyway, indeally I want these three main operations (find-file, grep,
>>> compile) to run in the inner sub-project by default. By typing
>>> something more, like, say, a negative prefix argument, I want to be able
>>> to be given the possibility to operate on the super-project instead.
>>
>> See the 'project-parent' implementation I posted a couple of days ago.
>
> I've seen it. In fact, I posted the same code earlier. But how do I
> plug in that so that M-- C-x p f, M-- C-x p c, etc, etc make use of it?
By modifying each and every command. I don't think it would be
appropriate for 'project-current' itself to react to the value of
current-prefix-arg.
As you are aware, some commands already react to prefix argument, and
some third-party ones might even handle the negative value. Let every
command deal with UI; we can make a helper that will make the code much
shorter anyway.
>>>> The idea of customizing the projects with a list of relative
>>>> subproject directory file names solves those downsides, but comes with
>>>> lack of automation: you have to do it for every relevant project, and
>>>> not forget to update the settings as the project structure
>>>> changes. Which might also be a pain e.g. when switching branches, if
>>>> your dir-locals.el is not checked in.
>>> As Juri mentioned, dir-locals-set-class-variables is the tool you
>>> need
>>> in those cases. There are ample tools to solve this problem. We should
>>> first focus on the project.el infrastructure that enables the above use
>>> case in the first place.
>>
>> What's missing in the infrastructure?
>
> Not much, I would say. But I think at least:
>
> * A way that I can add an element to project-find-functions that
> understands that a super-project has been detected already in the
> current search and proceeds to find sub-projects inside it. This is
> what I posted code for.
>
> * A way for M-- (or similar) to consistently affect all (or most) of the
> operations in the C-x p keymap so that we can choose if the operation
> operates on the super-project, if it exists. Unfortunately some of
> these commands (like project-find-files) already take a prefix
> argument to mean different things. But it's not too bad.
>
> * A new project type, similar to the '(transient . "dir") project (and
> inheriting most of its operations) that also keeps a record of the
> super-project found. This might not be strictly necessary, but could
> come in handy later for efficiency reasons.
Sounds pretty complicated. See if the latest patch solves your immediate
problems just as well.
Aside from the 'M--' thing, which is a compatible but separate story.
next prev parent reply other threads:[~2022-11-26 2:05 UTC|newest]
Thread overview: 139+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-16 18:37 Eglot, project.el, and python virtual environments Eric Abrahamsen
2022-11-16 22:24 ` Danny Freeman
2022-11-16 22:53 ` Eric Abrahamsen
2022-11-17 13:41 ` Danny Freeman
2022-11-17 18:06 ` Eric Abrahamsen
2022-11-17 18:48 ` Yuan Fu
2022-11-17 22:21 ` Tim Cross
2022-11-18 2:38 ` Phil Sainty
2022-11-18 7:43 ` Eli Zaretskii
2022-11-18 13:55 ` Danny Freeman
2022-11-18 15:22 ` Eli Zaretskii
2022-11-18 15:53 ` Danny Freeman
2022-11-18 19:36 ` Eric Abrahamsen
2022-11-18 15:06 ` Stefan Monnier
2022-11-18 15:17 ` Eli Zaretskii
2022-11-18 15:28 ` Stefan Monnier
2022-11-19 1:12 ` Dmitry Gutov
2022-11-19 7:42 ` Eli Zaretskii
2022-11-19 13:06 ` Dmitry Gutov
2022-11-19 13:14 ` Eli Zaretskii
2022-11-18 18:31 ` João Távora
2022-11-19 1:13 ` Dmitry Gutov
2022-11-19 1:56 ` João Távora
2022-11-19 15:23 ` Dmitry Gutov
2022-11-19 19:17 ` Danny Freeman
2022-11-19 19:49 ` Dmitry Gutov
2022-11-19 21:22 ` Danny Freeman
2022-11-20 1:51 ` João Távora
2022-11-20 15:36 ` Dmitry Gutov
2022-11-20 20:35 ` João Távora
2022-11-20 22:05 ` Dmitry Gutov
2022-11-21 13:45 ` João Távora
2022-11-22 15:48 ` Dmitry Gutov
2022-11-22 21:12 ` Stefan Monnier
2022-11-22 21:34 ` João Távora
2022-11-22 22:00 ` Dmitry Gutov
2022-11-22 23:23 ` João Távora
2022-11-23 0:03 ` Dmitry Gutov
2022-11-23 13:57 ` Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) João Távora
2022-11-23 20:33 ` João Távora
2022-11-24 2:49 ` Dmitry Gutov
2022-11-24 8:42 ` João Távora
2022-11-24 22:17 ` Dmitry Gutov
2022-11-25 19:56 ` Subprojects in project.el João Távora
2022-11-25 22:33 ` Dmitry Gutov
2022-11-26 0:00 ` João Távora
2022-11-26 1:57 ` Dmitry Gutov
2022-11-26 9:23 ` João Távora
2022-11-26 13:34 ` Dmitry Gutov
2022-11-26 19:36 ` João Távora
2022-11-26 2:01 ` Dmitry Gutov
2022-11-26 9:24 ` João Távora
2022-11-24 2:51 ` Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) Dmitry Gutov
2022-11-24 6:23 ` Eli Zaretskii
2022-11-24 9:01 ` João Távora
2022-11-24 22:11 ` Dmitry Gutov
2022-11-25 7:30 ` Eli Zaretskii
2022-11-25 17:24 ` Dmitry Gutov
2022-11-25 19:45 ` Eli Zaretskii
2022-11-25 21:57 ` Dmitry Gutov
2022-11-25 23:55 ` Subprojects in project.el João Távora
2022-11-28 0:41 ` Dmitry Gutov
2022-11-26 7:26 ` Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) Eli Zaretskii
2022-12-02 1:32 ` Dmitry Gutov
2022-12-02 14:16 ` Eli Zaretskii
2022-12-02 15:08 ` Dmitry Gutov
2022-12-02 15:37 ` Dmitry Gutov
2022-12-02 15:44 ` Subprojects in project.el Stefan Monnier
2022-12-02 23:26 ` João Távora
2022-12-06 14:36 ` Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) João Távora
2022-11-24 3:01 ` Dmitry Gutov
2022-11-24 8:50 ` João Távora
2022-11-24 22:46 ` Tim Cross
2022-11-24 23:38 ` Dmitry Gutov
2022-11-25 7:07 ` Bozhidar Batsov
2022-11-25 14:58 ` Subprojects in project.el Stefan Monnier
2022-11-25 22:29 ` Dmitry Gutov
2022-11-26 2:59 ` Stefan Monnier
2022-11-26 12:30 ` Dmitry Gutov
2022-11-26 17:32 ` Stefan Monnier
2022-11-27 0:25 ` Dmitry Gutov
2022-11-25 20:32 ` João Távora
2022-11-28 4:10 ` Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) Tim Cross
2022-11-28 17:21 ` Dmitry Gutov
2022-11-29 9:56 ` Subprojects in project.el João Távora
2022-11-29 18:40 ` Dmitry Gutov
2022-11-29 22:21 ` João Távora
2022-11-30 0:39 ` Dmitry Gutov
2022-11-30 0:54 ` João Távora
2022-11-30 0:57 ` Dmitry Gutov
2022-11-30 1:18 ` João Távora
2022-12-02 22:47 ` Richard Stallman
2022-12-02 23:46 ` Dmitry Gutov
2022-12-03 7:09 ` Eli Zaretskii
2022-11-24 22:58 ` Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) Dmitry Gutov
2022-11-25 2:38 ` Subprojects in project.el Stefan Monnier
2022-11-25 20:23 ` João Távora
2022-11-25 22:23 ` Dmitry Gutov
2022-11-25 7:42 ` Juri Linkov
2022-11-25 20:27 ` Dmitry Gutov
2022-11-25 23:47 ` João Távora
2022-11-25 23:58 ` Dmitry Gutov
2022-11-26 0:46 ` João Távora
2022-11-26 2:07 ` Dmitry Gutov
2022-11-25 20:16 ` João Távora
2022-11-25 22:44 ` Dmitry Gutov
2022-11-26 0:37 ` João Távora
2022-11-26 2:05 ` Dmitry Gutov [this message]
2022-11-26 9:42 ` João Távora
2022-11-26 12:38 ` Dmitry Gutov
2022-11-29 10:03 ` João Távora
2022-11-29 10:17 ` João Távora
2022-11-29 19:07 ` Dmitry Gutov
2022-11-29 22:52 ` João Távora
2022-11-30 1:10 ` Dmitry Gutov
2022-11-27 19:25 ` Juri Linkov
2022-11-27 21:43 ` Dmitry Gutov
2022-11-22 23:53 ` "Backend completion style" as a first-class library. Re: Eglot, project.el, and python virtual environments João Távora
2022-11-23 1:45 ` Stefan Monnier
2022-11-25 13:16 ` João Távora
2022-11-22 21:40 ` João Távora
2022-11-22 22:13 ` Dmitry Gutov
2022-11-22 23:33 ` João Távora
2022-11-21 20:58 ` Augusto Stoffel
2022-11-23 3:37 ` Dmitry Gutov
2022-11-20 16:37 ` João Távora
2022-11-21 7:54 ` Eric Abrahamsen
2022-11-21 13:36 ` João Távora
2022-11-21 15:41 ` Alfred M. Szmidt
2022-11-21 16:49 ` Eli Zaretskii
2022-11-21 16:49 ` Eric Abrahamsen
2022-11-21 20:54 ` Augusto Stoffel
2022-11-19 23:25 ` João Távora
2022-11-19 23:40 ` Dmitry Gutov
2022-11-16 23:18 ` Philip Kaludercic
2022-11-17 1:14 ` Eric Abrahamsen
2022-11-17 6:47 ` North Year
2022-11-17 18:09 ` Eric Abrahamsen
2022-11-19 22:36 ` Stephen Leake
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=79a17a5c-d1c1-ce69-d29a-9127150fb1d7@yandex.ru \
--to=dgutov@yandex.ru \
--cc=danny@dfreeman.email \
--cc=emacs-devel@gnu.org \
--cc=eric@ericabrahamsen.net \
--cc=joaotavora@gmail.com \
--cc=monnier@iro.umontreal.ca \
/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.