From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Nikolay Kudryavtsev Newsgroups: gmane.emacs.bugs Subject: bug#41572: 28.0.50; [PATCH] Support plain project marked with file .emacs-project Date: Sun, 17 Oct 2021 14:52:49 +0300 Message-ID: <444b6c1f-00f1-54ef-f692-cc3d6f30b93e@gmail.com> References: <2a70c748-e250-2f96-5d74-712b6d71e8be@yandex.ru> <871riitzch.fsf@gnus.org> <11e8e147-092d-d840-4d55-005654ff603c@gmail.com> <290a72b8-1e00-2e61-5665-a9bc2ca4289b@yandex.ru> <54c4b3c5-6142-2d2e-b531-a5e3d5a25e3a@gmail.com> <6f237243-8cd6-a22c-a5f5-d241d76ddd53@yandex.ru> <0895f33c-dfff-135e-657a-fbcf4730b799@gmail.com> <7814d113-5366-8614-8f5b-699800c303eb@gmail.com> <25a5eff6-3eed-92ad-7291-0b9c26f555c9@yandex.ru> <50249566-fc74-bed1-6a7d-52acc3876187@yandex.ru> 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="34422"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov To: Dmitry Gutov , Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 17 13:53:17 2021 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 1mc4j7-0008jz-EK for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Oct 2021 13:53:17 +0200 Original-Received: from localhost ([::1]:45308 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mc4j0-0003nK-Kc for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Oct 2021 07:53:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57534) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mc4it-0003lw-Dj for bug-gnu-emacs@gnu.org; Sun, 17 Oct 2021 07:53:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60361) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mc4it-0007GR-5C for bug-gnu-emacs@gnu.org; Sun, 17 Oct 2021 07:53:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mc4is-0002zM-Go for bug-gnu-emacs@gnu.org; Sun, 17 Oct 2021 07:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Nikolay Kudryavtsev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Oct 2021 11:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41572 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 41572-submit@debbugs.gnu.org id=B41572.163447158011480 (code B ref 41572); Sun, 17 Oct 2021 11:53:02 +0000 Original-Received: (at 41572) by debbugs.gnu.org; 17 Oct 2021 11:53:00 +0000 Original-Received: from localhost ([127.0.0.1]:43674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mc4iq-0002z5-Bp for submit@debbugs.gnu.org; Sun, 17 Oct 2021 07:53:00 -0400 Original-Received: from mail-lj1-f174.google.com ([209.85.208.174]:33749) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mc4in-0002yq-M8 for 41572@debbugs.gnu.org; Sun, 17 Oct 2021 07:52:58 -0400 Original-Received: by mail-lj1-f174.google.com with SMTP id d13so3352192ljg.0 for <41572@debbugs.gnu.org>; Sun, 17 Oct 2021 04:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=f0b9KbXWDtSVlnu7TuvRGzPU8wZ8oNCVp4+vziGUAVg=; b=qgomuDCUzum8KM5+1T86+T1TLQ2sGX9AoG9lmxq3B43+1Zb2uZ9mMPUSyDV1V5LVV0 1uZ1Cerlp5Tg/y1VdbZzNUoxb/hB8N3RBD1pp0WWWS3kv0VWEYPsDyWRkKi1mQ1/G9FC 1+6oEvQYgixYCbViWIDdg0hpyq3fDJuudfWQoV6tkCzKNW4qk/nvduFAIVN2NihrgNVd 05KbbsbmD5EnwYVrBJj/SorRsRRDEzjmCa2JjXmyWQzMU0R0bQdxG9CxJTJ6wHnQBhAo yMgW4iOby3Vq8qak/po31EVKH8HwAPFmpdGFkCR+6rrxp+XMUMoM3G24GLpTWuuUlYe8 4Mkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=f0b9KbXWDtSVlnu7TuvRGzPU8wZ8oNCVp4+vziGUAVg=; b=vG009y9nN6G49lMnSh75UQ7Pxr4NtAIthwns4HTej9NyVoQbEP2UnVpSSBIslMTSG1 KJuvcn2vhV2L9v3b2gy8Uders/DzvbFAOw55X8Z+wnNejqMRf+t+h4OvV7kk0dZ0uGb9 +Jh7ckBFu2fx7gGeXRjkzUtFzdqfPZzLIpXmny3zW9k0jSNFta+v0x+e8FCTJbmhrzSr 4djDGyjh4Nn+F94iGH3XRgBKL96KIAgTVoGfX8R/SBhw3QZ7j50Mg/IYXCJ/jrHxpGH7 6KDsy5x/S72ZcUYA6VPXxsG0t2yCoV8M51zPOigVtqBrSIoWwpNLmxaLb/ECclWHcdZi RIaw== X-Gm-Message-State: AOAM530a2AC5CrLeIIDfofduPKcqab4YeB2TtaYVkRaQ7rjhuQym6WqU 5SbeLF5rtGSsXXtz4mpeTAo= X-Google-Smtp-Source: ABdhPJwmH4bLkpt1eBpCGMGZoXrDs6vFSQTmFYJ/VDi7shYUqDAESG/dmPRGM87+zYGIjqsD86xkEg== X-Received: by 2002:a2e:3011:: with SMTP id w17mr24906873ljw.87.1634471571567; Sun, 17 Oct 2021 04:52:51 -0700 (PDT) Original-Received: from ?IPv6:2a02:2168:b115:9d00:6a3b:c091:5cdd:1851? ([2a02:2168:b115:9d00:6a3b:c091:5cdd:1851]) by smtp.gmail.com with ESMTPSA id b27sm1135306lfq.162.2021.10.17.04.52.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 Oct 2021 04:52:51 -0700 (PDT) X-Google-Original-From: Nikolay Kudryavtsev In-Reply-To: Content-Language: en-US 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" Xref: news.gmane.io gmane.emacs.bugs:217419 Archived-At: > Available how? Through a certain keymap, or a specially named set of > commands? These issues matter. Available through a function project-current-vc. On top of that you can implement (global, per backend, per project) setting project-honour-vc-ignores. Then project-vc-* utility functions. > If you don't care about the defaults, why argue on this bug tracker at > all? Because when you're discussing multiple complicated interconnected issues, it's nice to spot one you don't have to discuss. > But it's not reduced: quite the opposite, whatever the user adds (to > the beginning of the list) takes up a significant responsibility. It is relegated to the second class citizenship. Remember, here I was talking about your patch in particular. It puts file marker backends into a separate list, not the generic case of users adding new backends. > It's not the only possible solution to the problem, but I have yet to > see a complete design of some alternative being presented. I've already presented what I'm proposing in previous emails: (register-project-backend "project.file" priority :optimizes-file-listing nil :honuor-vc-ignores t) Instead of adding any separate lists the same marker find functionality can be implemented in a backend registration function and this would allow people needing file marker backends to implement them on the fly, whenever they need one. Also it's not touching the defaults in any way, leaving the decision about the backend priority to the user. > For instance, Maven modules can be reliably discovered from the parent > project's root directory, unlike the potential discovery logic for > arbitrarily nested projects (which seems like it will require a costly > directory tree walk). Yes. At the basic level it's a directory tree walk. But that's not a drawback of my particular proposal, since any attempt to implement the project unit functionality would suffer from this, regardless of the design chosen. You can implement any discovery strategy with any design. > It was just an example for what a "build tool API" could look like. If > you know better, try to propose a different one. I've already proposed one. Each project backend has a set of actions. An action is just a function. Since most would probably be simple shell commands in the project-root, some easier way to define those should implemented. You can see whichever actions are available in some interactive dispatch function or the menu. Actions can be grouped into action groups. This is better in my opinion due to not presuming anything, so if you need to group by a build tool or by multiple, you can, but you don't have to. > I meant a separate set of commands which would apply VCS's ignores to > the project operations, which the "current" VC-unrelated backend > apparently might not do, according to how I understood your explanations. That would a bit clunky. Just honoring VC ignores by default is much better, with an option to do the opposite. > Treating Maven modules as separate sub-projects *might* fit well with > that as well. If you can act on parent and child projects of the current, there's even less of a point to implement project units as a separate semantic unit(concept) from the project itself.