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: Fri, 25 Nov 2022 00:58:00 +0200 Message-ID: <33292672-2a59-ba63-05ab-a7995118a822@yandex.ru> References: <87zgcq68zp.fsf@ericabrahamsen.net> <4c5f4b07-3df6-d700-83f8-9a9d1b684afc@yandex.ru> <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> 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="2889"; 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 Thu Nov 24 23:59:12 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 1oyLBY-0000cD-Nc for ged-emacs-devel@m.gmane-mx.org; Thu, 24 Nov 2022 23:59:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oyLAd-00020Q-KP; Thu, 24 Nov 2022 17:58:15 -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 1oyLAb-0001zx-HN for emacs-devel@gnu.org; Thu, 24 Nov 2022 17:58:13 -0500 Original-Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oyLAR-0003up-Vw for emacs-devel@gnu.org; Thu, 24 Nov 2022 17:58:12 -0500 Original-Received: by mail-wr1-x433.google.com with SMTP id i12so4484292wrb.0 for ; Thu, 24 Nov 2022 14:58:03 -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=uCfH9hlmMSbllFm6JbdjzkS5l9jCmm2ABGToIXg8p+E=; b=D9l5wfXhRPv0zURVN0xnWW8xJhRNsLUZ/r3G6v0J2CzJzl5Xfdd3iwJFAv6Id7Dqly fjSrORDRBuk1r1/Za+HU6QQZKIz16K1xf1V25blynpLevgoVp38DQGID9GxzJtBezPz5 0JKusfeVwowBD+qLoEbqfSBNzjUSNJckB4EhXPNqjPu0sgdJTpEDcxHyV8Jx0tKx4kpx AYhWx1HkLMhe4/whZTk7QPULkmDXq4v8cjOUcdKxAQFbSWME/yBIXnVFXMQfL+G4Qv6T UoS09sg+HNTM/n5xIQ8tT+sYYd6BWMXVF6dwZaXanhPhQ1VkNdAakGcCAvEenHWykD+a tbsw== 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=uCfH9hlmMSbllFm6JbdjzkS5l9jCmm2ABGToIXg8p+E=; b=cdFS/EUDkXNYFTYzeA3kSyBe2Dr6UZKA6vL2OhBz7oyylA4sw1cRoDia0sKN3IQMgo qcLvwJe33vKAyKgjBoOqbI/uvaNAqLrs8nPlCvYX1L+/noe3o36WwOXWecHko1US2E0j aq59J2mwK8IX/eoJ70GS7LXDUo+NFNJ9v6L820xf7ULZzCl33YQ/2TAygDKXGEUojX5i iD9aweGvRxq2g+AnzZmBEc8t3/39/mlXqOfkIsGfAMojBOWzi9f3IRBfMlZ9uYOxjuIk OuMan1YH3BpKbwxbx3j5CRTlGdUYpC2fPoS/a1XBueV/LsNCIe+OUVTrSK7EMwgTabPU w8pA== X-Gm-Message-State: ANoB5pkS9PDuBVs8tNrwKJ4pz/KRWt/9w51zOkNe4QYs0X4IGXSrZczL +HLyPerxTzz2xrsIzanJooY= X-Google-Smtp-Source: AA0mqf7josqfxpB5QOrihMxERcb0wKoVh1ShEsYFIB7CH4ifShfXLHgMyM4cLQg0EYKBNsIbzis2iA== X-Received: by 2002:adf:e345:0:b0:236:2f7f:4c71 with SMTP id n5-20020adfe345000000b002362f7f4c71mr20545023wrj.585.1669330682664; Thu, 24 Nov 2022 14:58:02 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id m24-20020a05600c3b1800b003cf47556f21sm8289572wms.2.2022.11.24.14.58.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 24 Nov 2022 14:58:02 -0800 (PST) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a00:1450:4864:20::433; envelope-from=raaahh@gmail.com; helo=mail-wr1-x433.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.209, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, 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:300450 Archived-At: On 24/11/22 10:50, João Távora wrote: > On Thu, Nov 24, 2022 at 3:01 AM Dmitry Gutov > wrote: > > On 23/11/22 15:57, João Távora wrote: > >> It would be much more helpful in a dedicated bug report where we > could > >> discuss the details, collect the votes and see what kind of design > >> will ultimately satisfy the requirements. Instead of drowning it all > >> in this thread, which is only moderately related. > > I think we're doing fine here but I've changed the subject line to > > "unbury" it from the thread. > > You're fussy about proper bug reporting in your projects, but > somehow do > not extend that courtesy to others. > > > 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). Since we're back to examining customizable ways to mark projects, I invite you to read https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#82 too. > I can't understand what is discourteous about this. That would be not following the procedure the maintainer has asked you to follow. > I'm imagining that traversing a directory tree with an arbitrary > predicate is going to be slow. If the predicate is limited somehow > (e.g. > to a list of "markers" as base file name, or at least wildcards), 'git > ls-files' can probably handle this, with certain but bounded cost. > > > If the user wants marker files to mark the roots of subprojects, we'll > have to access the file system eventually because that's where > that information lives.  It would be a minimal and essential access.  If the > user is discontent with that performance hit (I really doubt it), then > the user may use other means to mark roots of subprojects, like > the one I suggested earlier. > > In particular, I don't understand where "traversing a directory tree" comes > in.  That part is completely absent from the solution I am putting forth. Your solution looks very similar to the patch in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#85, which see. Note that I have replied to your solution as well with a couple of questions, related to what is already written in the bug above. 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 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. They have an upside: it's economical to customize markers once, and then have them used for every project of yours, instead of having to edit dir-locals.el everywhere where needed. But the downside is that implementing the non-intersecting model of project becomes expensive: in the most general case one will have to traverse the dir tree to find the inner projects to exclude them. But if the markers are plain file names or wildcards, optimizations are possible (e.g. 'git ls-files'; which is still not instant, however), at least for Git/Hg parent projects. 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. Perhaps we'll ultimately end up with both ways to do this inside project.el, but that feels redundant.