From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Subprojects in project.el Date: Sat, 26 Nov 2022 00:44:16 +0200 Message-ID: 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> <87pmdau6wo.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7819"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: Stefan Monnier , Danny Freeman , Eric Abrahamsen , emacs-devel To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 25 23:45:26 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 1oyhRl-0001qJ-Oc for ged-emacs-devel@m.gmane-mx.org; Fri, 25 Nov 2022 23:45:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oyhQn-0007aE-Ah; Fri, 25 Nov 2022 17:44:25 -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 1oyhQk-0007Zv-4q for emacs-devel@gnu.org; Fri, 25 Nov 2022 17:44:22 -0500 Original-Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oyhQh-00046F-U1 for emacs-devel@gnu.org; Fri, 25 Nov 2022 17:44:21 -0500 Original-Received: by mail-wr1-x435.google.com with SMTP id n3so8666299wrp.5 for ; Fri, 25 Nov 2022 14:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=dadEyCfADVqxhcUP1LJ+DCPahoDtN8j19zyZEKqHUBY=; b=Bc6XYvQoWbvfZWAppHo5/XZjHKE9CjzxPLpx5/FjO/Q4mcaOvPYQikzG4Bg8Udn36t cxUUP/YJLFcYcHvZMc2vmhjuM3/OySRhPV85/u46WoBnzDCvw/HOoCpDVWK4bTPUxFp1 ppD7K6ZJkB6Tmctzl4oWkEceQoFK3Q6MIr35+fRkumckCOIQF9BkolZB1RyY28MqDnJm MNIsl5qAHByDZyvhzN84fvx5s6zaahYiemSouw/EGi7GJU2ZuK3diPNQunD5KhV8/CWZ E2SWwf8RF8k3p1PGel+CiBDcBPWJpH5M0nTA3h54ZuyEEYr3Iw5rPdMh8DCyGslLomrl VBDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dadEyCfADVqxhcUP1LJ+DCPahoDtN8j19zyZEKqHUBY=; b=uk+WpLq8VVtvN4oaXlg+40bunqDTwkQ2b5chGVOC3oDcI+luLiFugpRm7jXSs6oo0W yW4cTcWVuwCHzV7JaRqGup7i6GdDpufR1PgGQxXAlMOzFXBXXQ6weUpC9cnnGHCf4tIy 1a17MtThYAXKnaRWC1/nYQA5JBEkYac4Pu2ttFlvpxVW7fdZYQOuRvLCCILqzdBJfbm7 JkKEIULJ22s6A9fxD6M4QSklooR9S8n5QR4it5zdwU2hY/E/HKQUHhEiQntUj8P6hG0y AEuIKUQ8pB/3XoTWJjW4Jrf4yeM0uKXNGR6/F+9hn/ZA+noRbWU5fSd7HONI9dkpRJMy 9vcw== X-Gm-Message-State: ANoB5pmjg57/VZIXQexmjRQk0z99Rn2l8w8qpDoLXlinRwAU7k5yJtlJ /dBZlYO1gqFeTK7QqybV8mw= X-Google-Smtp-Source: AA0mqf7bhWCN3dGMiYvCNBWTGPIoel7uqfOD5oNqv1OZy6zkbt5wUS9UpXPzSqNndFOJZORCz2YgiQ== X-Received: by 2002:a5d:5e87:0:b0:241:e7a6:db08 with SMTP id ck7-20020a5d5e87000000b00241e7a6db08mr10905952wrb.349.1669416258201; Fri, 25 Nov 2022 14:44:18 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n9-20020a5d4849000000b00228692033dcsm4511115wrs.91.2022.11.25.14.44.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 25 Nov 2022 14:44:17 -0800 (PST) Content-Language: en-US In-Reply-To: <87pmdau6wo.fsf@gmail.com> Received-SPF: pass client-ip=2a00:1450:4864:20::435; envelope-from=raaahh@gmail.com; helo=mail-wr1-x435.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.243, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:300529 Archived-At: On 25/11/22 22:16, João Távora wrote: > Dmitry Gutov writes: > >>> I am indeed "fussy" about "bug reporting".  But here, Dmitry, I am >>> not >>> reporting a bug.  There's no minimum reproducible recipe, no error >>> to report, no surprising behaviour, etc. to speak of.  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. Like Stefan also explained, there are two different things one might be talking about when talking about "subprojects". >>> 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 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. >> 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. The technical solutions for this are plenty. The question is how to make a coherent solution from that, and to address the most common scenarios. > 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. 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. > 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? > 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. >> 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?