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: Sun, 17 Oct 2021 05:48:07 +0300 Message-ID: References: <5EpzudgjedeKADsX4_Tq-2WtNm3XKXmZjnEI7Y1lmw-Pcn_KrzKPD1o31Ele0JOIrZ1ITDdeQrOsJTHfGVPJlzyLhmqjxP3rmVVzou8KEBo=@thornhill.no> <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: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1908"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Cc: Zhu Zihao , Theodor Thornhill , 41572@debbugs.gnu.org, Juri Linkov To: Nikolay Kudryavtsev , Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 17 04:49:14 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 1mbwEb-0000Ml-KN for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Oct 2021 04:49:13 +0200 Original-Received: from localhost ([::1]:59204 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mbwEZ-00081W-GX for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Oct 2021 22:49:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38350) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mbwEQ-000806-B9 for bug-gnu-emacs@gnu.org; Sat, 16 Oct 2021 22:49:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60014) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mbwEQ-0007v9-2d for bug-gnu-emacs@gnu.org; Sat, 16 Oct 2021 22:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mbwEP-00043N-WC for bug-gnu-emacs@gnu.org; Sat, 16 Oct 2021 22:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Oct 2021 02:49:01 +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.163443889715531 (code B ref 41572); Sun, 17 Oct 2021 02:49:01 +0000 Original-Received: (at 41572) by debbugs.gnu.org; 17 Oct 2021 02:48:17 +0000 Original-Received: from localhost ([127.0.0.1]:43327 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbwDh-00042R-1r for submit@debbugs.gnu.org; Sat, 16 Oct 2021 22:48:17 -0400 Original-Received: from mail-lj1-f171.google.com ([209.85.208.171]:39625) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mbwDf-00042D-0P for 41572@debbugs.gnu.org; Sat, 16 Oct 2021 22:48:15 -0400 Original-Received: by mail-lj1-f171.google.com with SMTP id r6so1757872ljg.6 for <41572@debbugs.gnu.org>; Sat, 16 Oct 2021 19:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=e9dobGJOQh/GBOm/lG57DXoxlTBoEr2SCcgIevyQ0k0=; b=p9HejXQLNPieKPwhNb2u+ML4Vy5qvPEs43R13yp0pcLHudpjLol3zPg4GAOl5X+pit eF+P+7QmcOeOiV71IRJ3/k+H48IfBXf87yGnQnlZaTNyxKvi8O4/soAITdgJ4PytIWuU cBd/P8Uzntu/SH4nX4+WI1ukUQXHxeG8xSqKYBS54wQEffcDajiweKaZFUWBM8xHUrwM /oIvGNoL8lwZDqCksBPvPkisQhMMmP/krHHa/CFVHKa2m1DjR/Q/rxbndqN9DrPkSLJx BQUTQ4WlelXjqjpYQkLHDHRgff3GvsGkYiZPNKY3qr35VXsAHE+tayJCVSbCZaKo2Fg/ DonQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=e9dobGJOQh/GBOm/lG57DXoxlTBoEr2SCcgIevyQ0k0=; b=VMApCZkDus6P/aRPHsQmMbhXUYW5H48Kjr0TdAslA1VEBqk4bhPPvLQz32lOlb/zKh lnkoxwKIhN3fdbK3cqInvZf2fPTh4goqxbQqV4B4IPp1DmPPcIj9G3F64atNWDZkkGfP pEYb3LBotVr9ZOZkVSFPlrxPE+ltHZeEaEjtI1laccxLTSJLTEpCCl0g/HwcXcXb8TL5 WbZA7AXRtdIyBZK0d5rWpe7lci2ifsIaPq8N+kk4IG0Xz9xx3XUPGPYbGQwLAdP7kzTI YR37I8wvDUwxI11YQ37owwMHYu50KdbEN2eQ05rRZn2VtgqexhYpcMOKhFm6s08/zjCV aCSA== X-Gm-Message-State: AOAM531wa+kP3nAUKIroi83kqCXAaltSlr7gYOYA/UdcoJrkQJszmVrH P+UZJ+qFV5yx6hflbkS8MGE= X-Google-Smtp-Source: ABdhPJwaCmPE8MG8tV1Q+/rlSIag9Y3m3/8YV6bA648Skfpm5cKlLtxPDKSUy7fHTLxoot0mxkg03w== X-Received: by 2002:a2e:8793:: with SMTP id n19mr488571lji.176.1634438888897; Sat, 16 Oct 2021 19:48:08 -0700 (PDT) Original-Received: from [192.168.0.103] ([5.18.248.29]) by smtp.googlemail.com with ESMTPSA id x195sm1026137lff.28.2021.10.16.19.48.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 Oct 2021 19:48:08 -0700 (PDT) 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:217402 Archived-At: On 11.10.2021 21:05, Nikolay Kudryavtsev wrote: >> I didn't find a definite answer in the rest of the email, so I'll >> continue this thread here. > Lets restate the answer: VC should be available to the user regardless > of the current project backend. When it is so, you can use whatever > defaults you deem reasonable, with ignores being respected probably > being a good choice. Available how? Through a certain keymap, or a specially named set of commands? These issues matter. >> So you want to add a new backend based on GTAGS which also lists files >> by calling 'global -P' or something. >> I want all of those capabilities to be reachable, but we also need to >> decide which project backends configuration is on by default. > The question of default project backends is pretty irrelevant here. If you don't care about the defaults, why argue on this bug tracker at all? By similar logic, you can just go and write your own backends/apis/etc. > I'm > not suggesting adding anything there. I'm just saying that when the user > adds something, it should not be reduced to the second class citizenship. But it's not reduced: quite the opposite, whatever the user adds (to the beginning of the list) takes up a significant responsibility. That can be tough, however, so the first recommendation is to avoid doing it. And solve the immediate goals using something else. > The reason I've jumped in against your patch in particular is because > that's what it does. It makes a distinction between the (possibly) full > fledged function backends and the inferior marker file backends, which > get their own little ghetto. While I believe that we should treat such > marker file backends as first class citizens that are equal to any other > backend. They are treated just as any backend in the list. According to its modest capabilities, however, the backend is placed at the end. It's not the only possible solution to the problem, but I have yet to see a complete design of some alternative being presented. >> If the user wants to choose what to act on (whole project or current >> module), the information about modules needs to be discovered as a >> separate semantic unit. >  I don't think so. We have two options: > > 1. Nestable projects. In this paradigm any project can have however many > other projects in each subdirectories. You can go from child project to > a parent project pretty easily. Going from parent project to child > projects is a little bit harder, but still possible. Possible how? > So I can > compile(use custom action on) the parent projects from a child one, or a > particular(or all) child projects from parent. > > 2. Project units. Not gonna use the word "module" here, because we've > already used it for a different thing in this discussion. So one project > can have 0 or more units. Units cannot exist outside of a project and > are in turn are not projects themselves. Except that they can completely > look like projects, in cases like Maven or Makefiles. > > Option 1 is simpler because it has only 1 concept. Option 2 introduces a > second separate semantic unit, but I don't see any benefit from > introducing it. 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). >> Only if you intend to use the 'tags tool' as a build tool, e.g. list >> the available tasks or invoke one (for example, to rebuild the index). >> Then said tags tool can be put into build-tools-functions, with >> appropriate implementations for 'list tasks' and 'run task'. > I don't like such over-engineering, due to conceptually assuming that > all projects are build tool projects, all actions being connected to 1 > particular tool and each tool necessarily having multiple actions. I > believe all of this is better left to users and backend developers. With > just actions and maybe action groups, if we want them. Over-engineering? It was just an example for what a "build tool API" could look like. If you know better, try to propose a different one. >> Do we really want to ask everyone to use a separate set of commands to >> apply the 'ignores' config from the current VCS repo? > No? Separate commands is just another advantage of VC being always > there(if it's there). Maybe I'm maintaining a certain part of the > repository, be it a module or whatever, and that's why I'm treating that > part as a project, since that's the scope I normally care about. But > then I notice a buggy function and use those commands to look whether > anything else apart from my code uses it in the wider repo. 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. Overall, the idea about a separate keymap that will allow the user to act on the "parent" project is valid. Though it can be implemented on top of the current approach just as well. Treating Maven modules as separate sub-projects *might* fit well with that as well. But the overall idea of having lots of backends in the list, each describing a particular project type (marked by a particular filename) still look problematic to me from the practical standpoint (1. lower performance, 2. the problem of following .gitignore and the associated semantics seems unsolved).