From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Subprojects in project.el Date: Sat, 26 Nov 2022 00:37:30 +0000 Message-ID: <87zgcesg8l.fsf@gmail.com> References: <87zgcq68zp.fsf@ericabrahamsen.net> <87o7t2vj19.fsf@dfreeman.email> <877czqtyfy.fsf@dfreeman.email> <87zgcml7g7.fsf@gmail.com> <2ba04533-097a-a1da-ff3f-2c9506fd488e@yandex.ru> <875yf9bbzb.fsf@gmail.com> <87wn7oa0aw.fsf@gmail.com> <7a5b76fd-fb15-8c1e-ea29-bf11f7e0d2ae@yandex.ru> <87bkoya815.fsf@gmail.com> <0024a67d-b8e5-b35c-1b22-82541a170eb3@yandex.ru> <871qptai4d.fsf_-_@gmail.com> <33292672-2a59-ba63-05ab-a7995118a822@yandex.ru> <87pmdau6wo.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11930"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Stefan Monnier , Danny Freeman , Eric Abrahamsen , emacs-devel To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 26 01:37:04 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oyjBm-0002wL-Uk for ged-emacs-devel@m.gmane-mx.org; Sat, 26 Nov 2022 01:37:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oyjB8-0003Du-A7; Fri, 25 Nov 2022 19:36:22 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oyjB6-0003De-Q6 for emacs-devel@gnu.org; Fri, 25 Nov 2022 19:36:20 -0500 Original-Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oyjB3-0001PJ-RI for emacs-devel@gnu.org; Fri, 25 Nov 2022 19:36:19 -0500 Original-Received: by mail-wm1-x32e.google.com with SMTP id i64-20020a1c3b43000000b003d016c21100so7281795wma.3 for ; Fri, 25 Nov 2022 16:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=rrQ56gwuC0crlDZPOdbblVRiOfOGash/wKUyZvobZpo=; b=V2/suR5GVpLfGZ9L2wSVQgRJEg+SgR7eM4nAadUmr1K+94M2REVic2j8saO27IBTCu NOmudox/XstufNsrgbv0rrHzNnNQ5SqxfLjjYkwQHdixkhFcAWu1ER0HpjKhuDwb6qOl 7pH7QNoiF1LkbG+uWuqjHnNwHIm0tXcpq76PLvDDFIZRonebThpHRLrwOuz+gBsy11Lk yW/4SxlItRNciWGaGFpcDuonqRGv9K3GHjAd3FOXMakXb+ZS6lOqfm6sTSCYB0AkrLvw Dv8StipRUjhPSJlYZqZSuQIP06VoSYluXWrBTtKJYVZNffZuoKdKacYNu2RG9ttkSCBN nEqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=rrQ56gwuC0crlDZPOdbblVRiOfOGash/wKUyZvobZpo=; b=LTz8fmZ9RzXszu31E83yirL+u2Tn0tGdOu35fvq9BRRDTsoLYw8AmL0ok4yscDoI+G PSaTpP91DTpLg+Nk6vUC/zuyWNpJZVv8+ZHmcopvI7OT++jPBb015voCmrSOU0enh/4y 86NLJ8DVJeqSpEPt5KT5Td4bcXCR+pvfE48Go3+WD4fkDsP+vr+MnNrEif5UfEenMR36 H8f2nM96gVmIPFzV10rbS2ORmeRmIT0Nl+2znJozIpB2AM73vS2/URq39JWkiGrV+X/r md7z7iW7dNX1K56VlgjavdBLDFVMSaJEG5FCrPDsl8edpXoO+4EG+kzg3/MDefO3NUTc Kh/A== X-Gm-Message-State: ANoB5pn/vBBuSeEk8m4PToh97hBEh5JiC1IyX52ocJe8TJv1Cwz81Woh UXIHPSEof0xkPr2kKYS79nbqpjA6M/8= X-Google-Smtp-Source: AA0mqf5q/ffjrATNs9aUEL9yHgpi3r6ukhZQs75PNh5icQyTKFwh4jrL3J+DqQyywSNMmyrMnMVxWQ== X-Received: by 2002:a05:600c:5409:b0:3d0:5028:e963 with SMTP id he9-20020a05600c540900b003d05028e963mr273203wmb.51.1669422974544; Fri, 25 Nov 2022 16:36:14 -0800 (PST) Original-Received: from krug (87-196-72-177.net.novis.pt. [87.196.72.177]) by smtp.gmail.com with ESMTPSA id u1-20020a5d5141000000b002365cd93d05sm4678492wrt.102.2022.11.25.16.36.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Nov 2022 16:36:13 -0800 (PST) In-Reply-To: (Dmitry Gutov's message of "Sat, 26 Nov 2022 00:44:16 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::32e; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x32e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300536 Archived-At: Dmitry Gutov 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. >>> 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. >>> People do seem it natural to express their custom project structures >>> via file markers, at least that's what I see in the wild as >>> project-find-functions customizations. >> Yes. Very often there are already such markers in place. Other >> times >> you can add them yourself. Other time there aren't any and the people >> controlling the projects don't want you to add them (maybe because they >> don't use Emacs or care about your uses). >> But that shouldn't matter. >> My understanding of subprojects, or the operations I want to do with >> them isn't affected by the method by which they may be configured: >> that's a detail that relatively easy to solve. > > Have you read the bug I linked to? You don't need to explain something > I already know. If you're already perfectly aware of it, good for you. But this is a public forum, I'm explaining to all the recipients of this message what my understanding and use case is. > 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. >> 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. >> 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? >>> 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. Jo=C3=A3o