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: Mon, 11 Oct 2021 04:57:05 +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: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11069"; 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 Mon Oct 11 03:58:13 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 1mZkZw-0002lQ-Fk for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 Oct 2021 03:58:12 +0200 Original-Received: from localhost ([::1]:55422 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mZkZu-00078F-NZ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 Oct 2021 21:58:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56516) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mZkZm-000781-JL for bug-gnu-emacs@gnu.org; Sun, 10 Oct 2021 21:58:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44619) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mZkZm-0006oY-BC for bug-gnu-emacs@gnu.org; Sun, 10 Oct 2021 21:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mZkZm-00029N-AH for bug-gnu-emacs@gnu.org; Sun, 10 Oct 2021 21:58: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: Mon, 11 Oct 2021 01:58: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.16339174368191 (code B ref 41572); Mon, 11 Oct 2021 01:58:02 +0000 Original-Received: (at 41572) by debbugs.gnu.org; 11 Oct 2021 01:57:16 +0000 Original-Received: from localhost ([127.0.0.1]:56165 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mZkZ1-000282-W8 for submit@debbugs.gnu.org; Sun, 10 Oct 2021 21:57:16 -0400 Original-Received: from mail-lf1-f43.google.com ([209.85.167.43]:39625) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mZkYz-00027o-O6 for 41572@debbugs.gnu.org; Sun, 10 Oct 2021 21:57:14 -0400 Original-Received: by mail-lf1-f43.google.com with SMTP id n8so64459889lfk.6 for <41572@debbugs.gnu.org>; Sun, 10 Oct 2021 18:57:13 -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=gB8TfhIG++uz4ECgzrh0F5LlXO4/RYB99X5ziBFdQL8=; b=RyP1UlC2z1wMh4MFf9WPlwxC+O6gDFaoFKuySixsrV7zEXeMHqad9eh8CqaGh44CCZ dk2lXj2CPeJbIyFeHXdnTcOvX92IZ6AFnVq8b7TTokfnxHXLwYH/bHD10r72n/jBfcqh kc2MRPCsLm/yJvIPScWdwGfALTmXWlEylT7H71UTsENNeGnT53NlZitWLiZdTLXsr7+M TX0eEUFcKnbQweLEo1akoRGZ962kjO6/L9C7YG1wTqArcVDpHQiTiPdjd/+AGkcK5Ops h2GMxsys5+nTjN+UimskRv+RItdd0uMpmtngzlDDvjUk5DyA/u7cBooLwZ2B+St5GM3D Lb4w== 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=gB8TfhIG++uz4ECgzrh0F5LlXO4/RYB99X5ziBFdQL8=; b=AA3BNvwWiW0kBDWeMSbrpFShyBPrmn/4AE/3148X7BnKg6JOS+7VxOeegntm32OOUS 26M14VzWURAfKRlTaBI5l6qjm4c5MVZHw9H/YQyWE3UB+IKHrK7KtMY1PyIE0WepIVS/ +A9DghXp+6IstJOvsTj+OH+t0o/N+ApfbNQiENBJR/1zRBdANbHnwzmZ/hUrd7wyShqw KRZ5jjB+5+9sAq8mrOWaH84l1VzvEiwSVxbsr92W6FKECA0jCzJ7X0orZS7vptuytj5X vjkKRnA1l11Rv9biil/NKyLMBT8SNlIIK3b5c0iRI5knF8E4FYc4klDazGAhtx9nZVwr FJOA== X-Gm-Message-State: AOAM531+CRD38vJYynqqQOorgo9xJu0xGs1uJ01VmdFpwD2V6ffbaepV pYp9a+u9+DfY9GQ8Ant4qHw= X-Google-Smtp-Source: ABdhPJzSt+XNwsPdg4v785+vUL7od0sWzkBbHcPdGAXPcrCzeRZClyAWaOJe0/x+/XIR1NUXiCj+/g== X-Received: by 2002:a05:6512:68b:: with SMTP id t11mr26321135lfe.625.1633917427259; Sun, 10 Oct 2021 18:57:07 -0700 (PDT) Original-Received: from [192.168.0.103] ([5.18.248.29]) by smtp.googlemail.com with ESMTPSA id u21sm674362lju.26.2021.10.10.18.57.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 Oct 2021 18:57:06 -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:216848 Archived-At: On 08.10.2021 19:24, Nikolay Kudryavtsev wrote: >> What's your stance of having "filemarker" projects honor (or not >> honor) .gitignore instructions from the containing VCS repo? > That's a good question. I think at any non-VC project it is fine that it > does not honor it, since you get what you've signed up for. I'll come > back to this later in this letter, since another part of this > conversation sort of gives the answer to it. I didn't find a definite answer in the rest of the email, so I'll continue this thread here. This is the problem: semantically, it makes sense for filemarker backends not to honor VC ignores. But in practice, people will often (probably most often) want it to, or implicitly expect it to. Because when you are working on a subproject in a big monorepo, you might want to focus on its directory tree, sure, but you also expect that the global .gitignore settings are honored (where build artefacts, temporary files, etc, are configured to be skipped). You might also have additional per-directory .gitignore files which, again, are even more pertinent to the subproject, but semantically would not be expected to be honored. It's not good to have conflicts like that, between semantics and practical requirements. >> The problem is not being able to invent a variable, but how to honor >> it when listing project files. If the same backend doesn't have the >> information about the contained projects. > Yes, but at this point it's a separate feature request for a problem > that already exists at this point, it's just that we rely on other tools > to solve it for us. Let's say I maintain an application, except for a > module maintained by my colleague Bob. And since that module may be be > shared by multiple applications, it is version controlled separately. I > also may or may not want it to be considered a part of my project for > the sake of project utility commands. Here we rely on .gitignore and the > like. Lets say with GTAGS I can decide whether to include the bob module > too. But all of this works only because those backended tools happen to > implement this ignore functionality. So you want to add a new backend based on GTAGS which also lists files by calling 'global -P' or something. It's not enough to configure the root-finding logic for it, you also need to implement 'project-files' with the above process call. I also wouldn't want to enable such backend by default because it will only list files from a manually generated index, but not, say, a file that the user just created and saved. Not very user-friendly. But enable or not, that's beside the point: such backend fits the current approach well; whoever writes it can distribute it, and the users who want to prioritize GTAGS over .git can put it in front. It doesn't seem pertinent to what project-fallback should do. > Lets say your VC is broken and just > won't ignore some files(happend before in practice with VC) even though > it ordered to? So any such project-level ignore functionality, while > useful and would be even more useful with more weaker custom backends, > is not that important in the context of this discussion in my opinion. It doesn't really match my experience. Some VCS can be "broken" -- then we can ignore their equivalent of 'git ls-files' and use 'find'. We only have optimized paths for Git and Hg anyway. But even when we use 'find', we try to pick up the ignores configuration from the repo. >> This is an inevitably slow approach. Can be bearable in a local >> filesystem; might be fatal over Tramp. > Yes. That's sort of the unfortunate price we have to pay here. I think > some caching can be implemented, to limit directory reading operations > to 1 per level. "Some caching" has been lying around in TODO for years. >> I'm not seeing the concrete usage scenarios yet. > Well think more about either the 3 marker(vc, build-tool, GTAGS) example > or the Bob module example. Lets try to put it in your terms of > "correctness". Is me wanting the build tool to define the project > boundary over VC "correct"? Is me possibly wanting GTAGS backend to > define the project boundary "correct"? Is me wanting to possibly NOT > exclude the Bob module from the project "correct"? Lets say I've found a > broken function in the general application and I now want to see whether > the Bob module uses it too along with any other code by calling > project-find-regexp. You may answer no to all of those and say that Holy > Correctness can be only provided by the Holy VC backend, but I don't > think it's a reasonable approach. I want all of those capabilities to be reachable, but we also need to decide which project backends configuration is on by default. >> These settings, as I see it, will be on the project-vc backend. > Are you saying that if I want to declare that my make projects can be > subordinate to another build tool, I have to declare that in the > project-vc-backend of all places? What is a 'make project'? If you have 'Makefile' inside a subdirectory of a GGTAGS project, do you expect the said 'make project' only to include the files that GGTAGS has indexed? If yes, you need to have to integration with GGTAGS, one way or another. Maybe simply go through the GGTAGS backend to configure said 'make project', since that is the backend which is expected to honor the GGTAGS index. If no, sure, have a 'make project' entry in front of 'ggtags project' entry in project-find-functions. That fits the current approach well. > Again, not gonna repeat, myself on the ignore issue, apart from "you get > what you've signed up for". And going back to the ignores issue: I think we shouldn't expect the users to know the intricacies and the semantics of the project backend configuration before they can use the corresponding features productively. The default config should fit the majority use cases in a predictable way. OTOH, when you are well-acquainted with the nuts and bolts, you can built your own backend configuration, and you wouldn't care about the default setup. For such a user the current project-fallback definition is unnecessary: it is pretty trivial after all. >> I think it's apparent at this point that we are venturing into the >> territory of pretty invasive, backward-incompatible changes to the >> existing project.el API. > True, but currently the project.el is underutilized due to its > simplicity and due to this we can still do reasonable invasive changes > to the API. Not sure if that's true. According to the feedback, it covers the use cases of like 80% of the users. And the patches in this discussions should cover the remaining big holes which have been reported a few times. So... I'm fine discussing additions and even big remodels, but it would be better to consider those piece-by-piece, and probably in separate bug reports. We should still keep an eye out for performance, though, and the OOtB experience. >> Right, yeah. Having module detection on a hook seems more flexible >> than putting it on a method dispatches by project type, because then >> the Maven extension can work with any project backend, not just some >> specific Maven-supporting one. > The possible actions for Maven would already work any project backend, > it's the question of how to ensure the proper root for it. Yes. >> FWIW, Steinar asked for being able to choose whether to act on a >> module or on a project, and for that such separation seems to be >> necessary. > > I don't think he cares about Emacs having a distinction, more about the > abiilty to independently act on(compile) those parts. 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. Not sure how else it would be possible to implement such choice in user interaction. >> Debugging seems to be a separate feature from build tools (requiring >> its own information, and a fair amount of it). Although, depending on >> a language and environment, it might require integration with build >> tools as well. > Yeah, and that's one of the conceptual problems with that approach: > assuming too much. Project markers(or "build-tools" markers in your > paradigm) are not limited to build tools, it may be a tags tool for > example. 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'. > Even take Zhou's patch. Lets operate on the assumption that we cannot > let anyone go astray from the paradise of the Holy VCs correctness. > Every single problem you've mentioned would befall on those trying to > use a plain project. Adding a new backend would just let the heathens > win, since they can add those files anywhere and stray away from the > light. From such point of view, you can never add new backends, you can > only add new build tools. You can add new backends: you can add a bridge to Projectile, for example (there is one inside one of the reports in its issue tracker). Or you can create the backend based on GGTAGS, the one you described. As long as it's feature-rich enough, and the behaviors are documented, so the users know what to expect from it, it's totally fine. But both of those are more complex than the project-plain backend Zhou originally proposed, and the project-fallback in the latest patch. > Or to put it another way, whenever people want to mess with project > backends, what they want is to define a scope in which they want to > operate. That scope may differ from the scope defined by VC. I'd like to point out that this is already easy to do. > Also > there's nothing wrong in VC scope being available at the same time at > the user declared project scope. What I mean by that is that nobody > would complain if every project-* utility commands gets a sister named > project-vc-* that would allow you to the same operation, but explicitly > within the VC scope of the current project. Do we really want to ask everyone to use a separate set of commands to apply the 'ignores' config from the current VCS repo? I mean, it's nice to have the option for certain cases, but one would imagine this behavior would be more desirable by default, no? >> The 'project-vc-subprojects' patch. > This a solution to the subprojects hiding problem discussed earlier, > perfectly acceptable for me, but as I mentioned before is not something > I'd use much personally. FWIW, a user option 'do not exclude subprojects' could very easily be added as well.