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.bugs Subject: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Date: Tue, 29 Nov 2022 20:51:52 +0200 Message-ID: References: <87ftb92u8q.fsf@thornhill.no> <0ab90cf2-eab2-6fea-6698-4164d7753cd7@yandex.ru> <87d06ck2b0.fsf@thornhill.no> <2fbe5d5d-03a1-212b-9dd7-4723e168ad06@yandex.ru> <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <9781acc2-e4c0-b53c-6422-ef2e0a96f400@yandex.ru> <877czirqj6.fsf@gmail.com> <8a588083-3a00-a9e9-2d80-6885b64efbab@yandex.ru> <8735a2rt3l.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="14434"; 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: "Philip K." , Rudi Schlatte , Augusto Stoffel , Zhu Zihao , Theodor Thornhill , Daniel =?UTF-8?Q?Mart=C3=ADn?= , Eric Abrahamsen , Manuel Uberti , Juri Linkov , Rudolf =?UTF-8?Q?Adamkovi=C4=8D?= , 41572@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 29 19:53:13 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1p05jE-0003Tr-UM for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 29 Nov 2022 19:53:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p05j6-0001Ih-TV; Tue, 29 Nov 2022 13:53:04 -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 1p05j5-0001IZ-AS for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 13:53:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p05j4-0005lZ-Pc for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 13:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p05j4-0005cA-1q for bug-gnu-emacs@gnu.org; Tue, 29 Nov 2022 13:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Nov 2022 18:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41572 X-GNU-PR-Package: emacs Original-Received: via spool by 41572-submit@debbugs.gnu.org id=B41572.166974792521574 (code B ref 41572); Tue, 29 Nov 2022 18:53:02 +0000 Original-Received: (at 41572) by debbugs.gnu.org; 29 Nov 2022 18:52:05 +0000 Original-Received: from localhost ([127.0.0.1]:55670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p05i9-0005bu-36 for submit@debbugs.gnu.org; Tue, 29 Nov 2022 13:52:05 -0500 Original-Received: from mail-wm1-f51.google.com ([209.85.128.51]:43593) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p05i5-0005bW-CZ for 41572@debbugs.gnu.org; Tue, 29 Nov 2022 13:52:04 -0500 Original-Received: by mail-wm1-f51.google.com with SMTP id ay27-20020a05600c1e1b00b003d070f4060bso76154wmb.2 for <41572@debbugs.gnu.org>; Tue, 29 Nov 2022 10:52:01 -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=9d3Nk11cDhMVbrGMuLmGAg5WFKZ0IbgYUtKIx+N5x4Q=; b=hRY5nidImFdIQHe4xXgM8YNTJHgGesS356GlvEHyfZcOAyywrip/0K2rw5wUPdd6VZ VqxqUgsk6yxv1+TwNqWMYQ/LLp3+87xYwZxPQNuP3ve7F0MBQCZeZvodHQ3qiRTKcXaH znHTTGJjHuuQWUGxgqFmyj7vf8MvLMTbVrgUsHWeu60O9rDzvoTmy7xG0cQOOUajeFBq zQlsfq3afkelWq7aapjbegbdxPaJccFGCXaEXebl1ucEgT0mu0/M9kWJX93g1F5s28W2 kvjMlQkWNJgQXQmV7+aszylhJ/hMkjOUqPv+6ucAnV71fkOVVBREopxEvewqvCXym9ra PDDw== 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=9d3Nk11cDhMVbrGMuLmGAg5WFKZ0IbgYUtKIx+N5x4Q=; b=xs47wEejJVUaPJmQ3NJINk840c/6o7L3+bMg7+gowXZs7eVFM17B0xnStYTFStrPrx Z05rcBhu8MYK4BNYha8GYUNwnKkBbqtRT4LDD7dUmd9mPZ8La9G3mBRJXiTrGdZ2n0Vw 8x4n2+Dd6c5FCZwoW8Y/ptXa1fnkuk0iMzOvwYhVRrRMegETuc0EAwrtWh0k0XPZCARo fuZb9nrZ1xSnzxsM6UJn8kcGO9IqoSLuXrJqzLYakvQpOOA1r/+DYOGHg6czbsUq5HI7 F08tBj2skZmgwtXefTVSkT7fdyKgA5REA1H1A2zdr8hyNxhRY11DLYzXIfDVqQW3/4f4 cZ6g== X-Gm-Message-State: ANoB5pk9FN3RibC7WzcIofAbUfbBHO+Xi5mDJFIaJn1131AhegGkPHaz texb7lsTrKz1qgDf9uQh0TA= X-Google-Smtp-Source: AA0mqf5DXHtBil/T/b0UirmxODr3pK4EGP7RaBtcXd91x5lgoAXvO7w/WOo2aOVRhMGhhg7mjfK2XQ== X-Received: by 2002:a7b:cb91:0:b0:3c6:cb54:ef66 with SMTP id m17-20020a7bcb91000000b003c6cb54ef66mr32119657wmi.90.1669747915324; Tue, 29 Nov 2022 10:51:55 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id m9-20020a05600c3b0900b003c5571c27a1sm4296498wms.32.2022.11.29.10.51.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Nov 2022 10:51:54 -0800 (PST) Content-Language: en-US In-Reply-To: <8735a2rt3l.fsf@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:249424 Archived-At: On 29/11/2022 11:46, João Távora wrote: > Dmitry Gutov writes: > >> On 26/11/22 21:23, João Távora wrote: >>> On Sat, Nov 26, 2022, 12:30 Dmitry Gutov >> > wrote: >>> > My use case is the following: I'm interested in being able to >>> designate >>> > projects (through various means, not only marker files) that may only >>> > exist inside other projects. >>> You previously described your super-project and how you handled >>> it >>> using >>> project-find-functions hook with a new element that looked for file >>> markers. Does this patch make that easier to do? Without writing custom >>> functions? >>> The example i gave did _not_ use file markers. Personally, I can't >>> use them. I need some elisp way. >> >> Please elaborate. > > I've already elaborated, with actual code. > > https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01505.html > https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01530.html These answered the question of *what* you want to do, not *why*. >> Does it mean that those subprojects are chosen manually and don't have >> "packages.jon" or etc exactly (or that too many subprojects in that >> same project would, undesirably, contain the same files)? > > OK, one last time: packages.json and i.e. monorepos that have a > developing collection of similarly structured NPM packages that move > around is good case for marker files, undoubtedly. I'm not putting that > into question. > > But many times that's not the case and you have a big project in which a > mostly fixed heterogenous collection of sub-hierarchies exist and you > would like to designate as those as subprojects. In the latter case, > marker files are useless, uselessly slow and perhaps even impossible. I understand that in theory, it's just it's often possible to solve the problem with the tools at hand (see my latest reply on emacs-devel about the Emacs doc/ subdirectory). So I figured to ask about your particulars. > In _both_ cases, it's very useful to have project operations let the > user choose the target: super-project or sub-project (or "parent > project", "outer project", "nested project", "inner project": I don't > care too much about the nomenclature). Yes. But separate feature. >> Would being able to set to absolute file names (directories) help? Or >> would that be too awkward? > > That's more or less the idea, but they don't need to be absolute file > names which is indeed awkward See project-sub-project-prefixes in the > code I posted. project-sub-project-prefixes can even be a regex pattern > applied on the super-project's root. This describes the heterogenous > collection economically and robustly. It is then typically set > dir-locally, with either a .dir-locals.el file or with > dir-locals-set-class-variables. I asked about absolute file names because those would be easier (semantically) to cram into the same user option as the markers. Otherwise we'd need a separate option for those. Although... if we insisted on using the format like "./abc/def/", that would also put those values into a different category. The handling logic would need to be different just the same. > Of course, the member of project-find-functions that consults > project-sub-project-prefixes needs to be aware of containing > super-projects found by some other means (marker files included). See > the code I posted to emacs-devel for a possible implementation. Have you tried the patch that I sent in the GP email?