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 (Was: Eglot, project.el, and python virtual environments) Date: Mon, 28 Nov 2022 19:21:55 +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> <86bkowdjx5.fsf@gmail.com> <43aa2f10-d947-dfcd-82b0-f6f1be3aaaec@yandex.ru> <86cz97jzpi.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14361"; 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: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Stefan Monnier , Danny Freeman , Eric Abrahamsen , emacs-devel@gnu.org To: Tim Cross Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 28 18:23:10 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 1ozhqX-0003aF-Tf for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Nov 2022 18:23:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ozhpc-0003sp-5f; Mon, 28 Nov 2022 12:22:12 -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 1ozhpT-0003sF-NR for emacs-devel@gnu.org; Mon, 28 Nov 2022 12:22:03 -0500 Original-Received: from mail-wr1-x436.google.com ([2a00:1450:4864:20::436]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ozhpR-00040P-FD for emacs-devel@gnu.org; Mon, 28 Nov 2022 12:22:03 -0500 Original-Received: by mail-wr1-x436.google.com with SMTP id v1so17985323wrt.11 for ; Mon, 28 Nov 2022 09:22:00 -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=VPGWXR4KTU+aRh3cquvJcg591r+hRg/H7JUh4hZjg0E=; b=CBer2utqTu0WMJmTtkeZ+tScy+y7WNS9VK0/v8w9tWgJIqNAyxaaqrrp5kD2bwbkUi t6o3dGuJRY6cXnbehK2vHbog/rs1SFSD5pkMIy0kKvKVBGGcT79w6jSOqoIka8ZGjRG0 96zTLUkt5BLjhMItIN8oVOos21oiq51i5yLVj73n0nfjuGudsPbRnnKmGE8PKnc06R3x NUCqgtJnUtr7H3+QntMngqvrGHAQY/3AsKIkPqctFFpF73xzWKmabwIbYOJkZ1IjNRMH 6i4kd7P0MpUlIT4+xe4j/7wsgJDnKAkDnVAOULGWpTfwoAuw9EOoSJ9nva0GG26hwqs3 cVog== 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=VPGWXR4KTU+aRh3cquvJcg591r+hRg/H7JUh4hZjg0E=; b=ftbLltl+5/iFSQP/sUVMBFax/nh7wYY3DTFcKXv3OWFBXGazxMyhkk0dhTuJURERU4 +tDUNdHR3JPpZnvyeYLtfS3pQhaqJ3e5lx6QEcjYW5E0k0VLXbllWFPKrMtrFXPG96YB /kbg7uFbXQ6irw/K0eVcB2kiLUGAN3JC1OfKngLGgUG7N8SiBAs8LOvtAaQQztUBRVAP M2jzbY38RlRHd5URyHR9Arv94KkuDGrxujKgRXOPNnuPSEzrMg2Zuba7zm63vPzuDDmz bvMh4V0tTkoaq6OXca1ITzo7rcNq/f0OtzgCRVPhfZg1FaUuu7R5YiLzepPaBX1kY7eM L62A== X-Gm-Message-State: ANoB5pkMPpOjbCfCC2W+R2YcOEweIWj0KjaB0R0fQaTQpbQ8dAfwCQOs QKMzSrKZh1pWJ4yyG8xQlKE= X-Google-Smtp-Source: AA0mqf7peS9gyW0DXUyxOZNpZbbDZJd11ASGV+OZWNy4GbzPHiPY1qHkA3bEi7cNnk7XrUORDRaD1A== X-Received: by 2002:a5d:684d:0:b0:236:5ede:9f8e with SMTP id o13-20020a5d684d000000b002365ede9f8emr33181835wrw.372.1669656118137; Mon, 28 Nov 2022 09:21:58 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id h8-20020a1ccc08000000b003cf6c2f9513sm15790563wmb.2.2022.11.28.09.21.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Nov 2022 09:21:57 -0800 (PST) Content-Language: en-US In-Reply-To: <86cz97jzpi.fsf@gmail.com> Received-SPF: pass client-ip=2a00:1450:4864:20::436; envelope-from=raaahh@gmail.com; helo=mail-wr1-x436.google.com X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.257, 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:300676 Archived-At: On 28/11/2022 06:10, Tim Cross wrote: >> OT1H, large projects are relatively rare. OT2H, having a need for subprojects seems to be >> correlated with working on large projects. >> >> What is the common case, in your experience, and how is it better solved? Globally >> customizing a list of "markers", or customizing a list of subprojects for every "parent" >> project? > > In my personal experience, sub-projects have been more about project > structure and not size. I would agree they are more prevalent in large > projects, but can exist in medium and even smaller projects. Sure. > I don't think I have a preference for customizing a list of markers or a > list of sub project definitions per project. I suspect different > approaches will work better in different scenarios and neither is a > clear 'winner'. However, as pointed out by Stephan, terminology > confusion/meaning may well be contributing to the confusion here. Not > only am I unsure everyone is thinking the same thing when talking about > sub-projects, I'm not sure everyone is even talking about the same thing > when referencing 'project'. I suppose another way to look at it is, subprojects could be defined by technical boundaries (e.g. this dir is a frontend SPA, and that dir is our backend), or by social (we have a monorepo, but this dir belongs to our team). The former approach should be easier to support reliably using markers, and the latter -- not necessarily so. But I'd be happy to find out that 98% of our users' cases can be handled with markers. > I wrote a lot about how I use projects and sub-projects in my work flow > and then realised it probably isn't helping that much. It struck me that > perhaps the issue is that the notion of sub-projects isn't really that > useful in itself and may actually be more detrimental than useful. It all depends on the individual workflows, for sure. > When you think about it, a sub-project is really just a more narrow > project focus. A project is really just a collection of files and > environment settings which can be considered, for some purpose, as a > 'unit' in itself. It might define the set of files used when considering > find and replace for a symbol, when looking for symbol completion > candidates, or file/buffer switching, opening, linting, cross > referencing etc. It may correspond to a VCS repository, but it may > not. It could cut across repositories, or it could be made up of > multiple repositories or it could simply be some bespoke virtual project > concept specific to a particular use case. Enviroment settings -- we do not support (yet?). But depending on the person and the goal, dir-locals.el can help quite well. Regarding cutting across repositories, etc, there is a line for cases wre can easily (or with minimal customization) support ooutb, with auto-detection that a lot of the users prefer. Versus very custom shapes which require one to write a custom backend. But if someone has a particularly handy way to define an arbitrarily-shaped project, they can submit that backend for inclusion as well. We could call it "free-form", or something. > I guess what I want is the ability to define arbitrary collections of > files and environment settings as a project, have a way to select/target > a project and an API which various tools can use to get the files or > environment settings to then operate on. Whether one project can be > considered a sub-project of another project is less relevant compared to > the ability to select/identify the target project. Automatic definition > of projects based on VCS repositories is great and a real time saver, > but the ability to define what makes up a project manually is also > important. The ability of the system to automatically determine which > project is 'active' (for example, based on the location of the file > being opened) is good and having the system prompt you when it isn't > clear or when there are multiple options is useful, but just being able > to run a command to set the current project would also be > sufficient. However, how one project relates to another project i.e. sub > project, main project, etc, seem of limited use compared to just having > the ability to select a sub-set of the files and environment settings of > a project, whether we call these sub project or nested projects or > whatever, seems of limited benefit. Regarding the latter, there are a couple of requests now to be able to run a particular action (project-find-file or project-find-regexp) against either the current project or the "parent" project (determined by the locations of the root dirs), based on the prefix argument. That seems reasonable enough.