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: Mon, 11 Oct 2021 21:05:57 +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="32136"; 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 Mon Oct 11 20:07:16 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 1mZzhk-0008Cb-1y for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 Oct 2021 20:07:16 +0200 Original-Received: from localhost ([::1]:51434 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mZzhi-0005Rh-Ru for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 Oct 2021 14:07:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33476) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mZzhX-0005Oj-Iz for bug-gnu-emacs@gnu.org; Mon, 11 Oct 2021 14:07:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49323) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mZzhX-0004z7-A3 for bug-gnu-emacs@gnu.org; Mon, 11 Oct 2021 14:07:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mZzhW-0004Gt-1J for bug-gnu-emacs@gnu.org; Mon, 11 Oct 2021 14:07: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: Mon, 11 Oct 2021 18:07: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.163397557516363 (code B ref 41572); Mon, 11 Oct 2021 18:07:01 +0000 Original-Received: (at 41572) by debbugs.gnu.org; 11 Oct 2021 18:06:15 +0000 Original-Received: from localhost ([127.0.0.1]:60869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mZzgh-0004Fm-Fo for submit@debbugs.gnu.org; Mon, 11 Oct 2021 14:06:15 -0400 Original-Received: from mail-lf1-f48.google.com ([209.85.167.48]:46015) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mZzgb-0004F9-9L for 41572@debbugs.gnu.org; Mon, 11 Oct 2021 14:06:09 -0400 Original-Received: by mail-lf1-f48.google.com with SMTP id u18so76783128lfd.12 for <41572@debbugs.gnu.org>; Mon, 11 Oct 2021 11:06:05 -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=4a1aOAWE1Cvue3PlD2lW0+MXmJWE+IR2lRg8BeSDyFw=; b=H37h94WQQWPRvmgfLUbRIzp+WZbAtu2I178CQd0LnVEdJlxnopI5XTInNDZwMpAJtd WlS93p9BkCgu0k5oHR3Qo16wNiMYAP5vDfxEta1KZZ95gpqFpFLzu2XqpzjYheoUvVpT tfSRvHvF2pjmPUAxqFouJfoxC/pAJ32Q+6l89Oc01H5GXnmbx10r+TPoeeuy5mFCmHYf r54fLkGSm4LfZBLe9+jT/oRYVT++/0sAg/5DF/GQpXgy2D801jiYM/Bj7Q/9A6pbLk5C ZWv3Y07wb1hbN/5r4m9WzvMFNRfVmhqyaP8DjhfZraW/mkhTlensr9TIkcF0+gmiMcBd AvQQ== 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=4a1aOAWE1Cvue3PlD2lW0+MXmJWE+IR2lRg8BeSDyFw=; b=qlFeMsCx8I6UpPSydIFFy2HduuvHjdRhfGRd1cn5T+sz3H0MkUFTx2mvuzv+Du0WCw tJcdSZ63NUtEeNlB5lW/SD1xMovxLMtfQS8nhNsp4m3gbk3z9KCc2Nf2zE729dR5oX7/ nDll5VzLV8X5yMJbl8g1BehZeRFZcw9INMyPQ8VJxOZvoXgXBZqhUfm5MaYB7kBeZEL2 yEEIoVgMWlF1IZOpx6diJ+WCpboI1uz/pHaKgybF9APqTsLttVUx5XVTuRAsxiFlj0Ba WakL/f+tofoSAkWmMBM5pyydnGvK3fm1IGUhj3SkmYZJnCeLtjyvlPj0O9M+eNJSfa15 8+wg== X-Gm-Message-State: AOAM532fJJOBa9Yw5WGhgcc0oNKC11mhr/paauEmcY0/iwTN0FoF0lpD t6V7r7do0qq40rvUUqtv5sI= X-Google-Smtp-Source: ABdhPJwu4aF06c/6S2eZoSsen3scaMYmsuqnJ1bOT3NvKJ0bhl0gJ7jlXJWThu9kYHB+SkZQy1Og2g== X-Received: by 2002:a05:6512:3981:: with SMTP id j1mr28227501lfu.417.1633975558878; Mon, 11 Oct 2021 11:05:58 -0700 (PDT) Original-Received: from ?IPv6:2a02:2168:b115:9d00:e427:25ae:e312:5fb9? ([2a02:2168:b115:9d00:e427:25ae:e312:5fb9]) by smtp.gmail.com with ESMTPSA id m14sm909748ljp.12.2021.10.11.11.05.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Oct 2021 11:05:58 -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:216949 Archived-At: > 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. > 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. 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. 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. > 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. 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. > 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. > 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. P.S. Sorry for the terrible amount of typing errors in my previous letter, too much writing for me last week.