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: Fri, 25 Nov 2022 20:16:07 +0000 Message-ID: <87pmdau6wo.fsf@gmail.com> References: <87zgcq68zp.fsf@ericabrahamsen.net> <84781346-5b88-2be5-38bb-02696fcf1364@yandex.ru> <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> 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="13986"; 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 Fri Nov 25 21:15:28 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 1oyf6e-0003Sp-93 for ged-emacs-devel@m.gmane-mx.org; Fri, 25 Nov 2022 21:15:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oyf69-00085Y-Vk; Fri, 25 Nov 2022 15:14:57 -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 1oyf68-00084U-9o for emacs-devel@gnu.org; Fri, 25 Nov 2022 15:14:56 -0500 Original-Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oyf66-0002nn-B3 for emacs-devel@gnu.org; Fri, 25 Nov 2022 15:14:56 -0500 Original-Received: by mail-wr1-x42f.google.com with SMTP id i12so8382964wrb.0 for ; Fri, 25 Nov 2022 12:14:53 -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=9sob5KYHt2WlRG/16xbtRhUEwanH1/xea1U3Rtz/n00=; b=UsCgD/zMV2pDV8m50kZlKoAKGLRc0p55n9ylOE8sNGPnFvQywP5JiPPUeWi5W9USjB 3kmjtgWTPH82+wC1C2od3OG5ollwCeZtWvdzQkodcSMgxPuhXM/0BN8Wt1BquKedxnFQ sWfx4blxIT59TL6KNCBuLZs+kZ5mv+nFu4+T6cBRw2RRCPaF68Ycrf8tBRegxQP98BQj gG3XRjGZveNaBypJgzpME/DlD34tf82lW6e12BsoB1O7B7jLz8Fs4zAhh64HOIubR5uH cjSAqgUKK3t2seFb/j91ct5Gcs0Nf3NzPxqjy4UbORlLHHWFvki4XUkTCx+o/sACyMwA xv7g== 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=9sob5KYHt2WlRG/16xbtRhUEwanH1/xea1U3Rtz/n00=; b=MYc+8YIhx2rmMbRUQPkSl0gy6Lf6gpPodL1ktClFt5EXP/qd7ZibPnSp5aED/ZikoW gcFjDXhlxnm97+Y9K5bk4T7uFf4uCd6AhsrgrhYDnhOMRJk5IOOqsFo+Ymqa6bwN5Q/F yu3Nbgs9NpxN38g9MkhwjEHxmG5d27fP4L3G2J8HWWWQFRQ2lTCVP8e94WckECopk9jI GrGv/evxD59R56zSajXK/t9E49YCGiUaE9N8brCIsMjYnoeFTEJMBe6E6QMGcrB90UlO ZoRcDd7hlOgnZYJ1moYHCCSd+PM3EgCmAqUWEMya6p8+V+3XMiE5z86e7NXsCeplOJOG Dn7A== X-Gm-Message-State: ANoB5pluTE0dtJSfk66Phlypo4U8ZYC+Yx+7z0taIQ52xjb0UptY33iG 1LQ1cyoIOtnxrYkvc9ubsdajIZDEsjY= X-Google-Smtp-Source: AA0mqf7wdvXIjHsZJvaxNVInFS4Z7Y9mp+tIIGoF2vQMOpKywF46tZB9wHzYcyccEkaZPtN3i8zKSg== X-Received: by 2002:adf:d4cd:0:b0:241:fc9e:fb90 with SMTP id w13-20020adfd4cd000000b00241fc9efb90mr6302756wrk.430.1669407292679; Fri, 25 Nov 2022 12:14:52 -0800 (PST) Original-Received: from krug (87-196-72-177.net.novis.pt. [87.196.72.177]) by smtp.gmail.com with ESMTPSA id w16-20020a5d5450000000b00241db7deb57sm4403749wrv.114.2022.11.25.12.14.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 25 Nov 2022 12:14:52 -0800 (PST) In-Reply-To: <33292672-2a59-ba63-05ab-a7995118a822@yandex.ru> (Dmitry Gutov's message of "Fri, 25 Nov 2022 00:58:00 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::42f; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x42f.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:300519 Archived-At: Dmitry Gutov writes: >> I am indeed "fussy" about "bug reporting".=C2=A0 But here, Dmitry, I am >> not >> reporting a bug.=C2=A0 There's no minimum reproducible recipe, no error >> to report, no surprising behaviour, etc. to speak of.=C2=A0 We're just >> discussing Emacs development... in the emacs-devel mailing list. > > You are making a new feature request. Or at least were (when you were > talking about "subprojects" as a new noun for project.el to have, with > new associated behaviors). I'm discussing a limitation of project.el regarding subprojects. If that is solved with a new feature, a new package, or if it turns out it's not a limitation at all, I think it's a worthy topic of emacs-devel. >> 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. > 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. > 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. To be clear, here's my use case again: I have a complex hierarchy of directories and files which call the super-project. I sometimes want to find files, grep for strings and run compile commands there. project.el allows this already (albeit with associated find-file slowness if the project is really large). Sometimes I will work for some period exclusively in one of the super-projects's sub hierarchies. When doing so, I will look for files, grep strings and run compile commands in that hierarchy which I call the sub-project. Doing so cuts down on the noise of other files and grep matches in other parts of the super-project that I'm not interested in. 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 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. > 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. Jo=C3=A3o