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: Thu, 7 Oct 2021 05:27:38 +0300 Message-ID: <25a5eff6-3eed-92ad-7291-0b9c26f555c9@yandex.ru> References: <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> <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> 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="37861"; 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 Thu Oct 07 04:28:10 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 1mYJ8j-0009dg-QJ for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Oct 2021 04:28:09 +0200 Original-Received: from localhost ([::1]:45446 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYJ8i-0000be-23 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Oct 2021 22:28:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41886) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYJ8c-0000aF-7X for bug-gnu-emacs@gnu.org; Wed, 06 Oct 2021 22:28:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34193) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mYJ8b-0007ax-Uy for bug-gnu-emacs@gnu.org; Wed, 06 Oct 2021 22:28:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mYJ8b-0001Ek-JQ for bug-gnu-emacs@gnu.org; Wed, 06 Oct 2021 22:28:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Oct 2021 02:28: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.16335736724739 (code B ref 41572); Thu, 07 Oct 2021 02:28:01 +0000 Original-Received: (at 41572) by debbugs.gnu.org; 7 Oct 2021 02:27:52 +0000 Original-Received: from localhost ([127.0.0.1]:45739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYJ8S-0001EN-32 for submit@debbugs.gnu.org; Wed, 06 Oct 2021 22:27:52 -0400 Original-Received: from mail-lf1-f45.google.com ([209.85.167.45]:42709) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYJ8M-0001E0-Ef for 41572@debbugs.gnu.org; Wed, 06 Oct 2021 22:27:50 -0400 Original-Received: by mail-lf1-f45.google.com with SMTP id x27so18290732lfa.9 for <41572@debbugs.gnu.org>; Wed, 06 Oct 2021 19:27:46 -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=CF63bVNaGCXVB1JXL51VgDjvaxJA2XwX7ewLROuZBWg=; b=BSXKY9KmcvxzVKiYHfUwl85vgF/szWjTdHoK/jr2RU4QxPVvBrrYukGPt1v8dPOe0w wwaQq5yiK2yO1ZlhrphQGB+zNf1+ofpKJru3tDs8EV/SFoNMHonl4j1Y5bsNbHhZHBqg ShIyeoF91gZ4u298Yy39hjjT8Vh6MQVWmGXxEEKPyJORejNTTV+hJJile9s0hk+DGq/r o5Fs9RMW/7SXdGaj0RX+VC6L0GBwjU9nXG1BouyuRtUyaa9KzlACDktM2eW75Nzz1qh4 xhyOrspfwQATjzzasJFmLb6hq4Ege1PdovmFZI5n7Es69T+zh9jsrF/lXG2QufiqvfnW oCwQ== 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=CF63bVNaGCXVB1JXL51VgDjvaxJA2XwX7ewLROuZBWg=; b=JkWMNXWs/N3VAMojtetA8EBPo9UZu6g20mjXS/tCMzRSbDoVx5el4lJBS3bSK5q81L byFca36pda7zTM8svmDFWPfEFG2BZrLXM0RFQg2HIGms+0RxJ6ATHaY4ZNSX0gfvK1XX 4ugngh3N1w/V/4y8+mn2v/qDHCd+0BQWZQsxiW+GW1RXPPIWMvU2k7HKM7ApwpI+4V1v +3CJCcEcTlyzlnQ9C1NHZxUXupt4c/dX44e/UCdziZa9/IYTsaV0Qq1EF/8KJmReE2mN hHHWhkRUnEZQjfK3uMawA1x510TOo1vYT152yf0wUutAkDgycAR3srWkc5A25Kf9itdD Ltag== X-Gm-Message-State: AOAM533f9eKHbKErzWdC0Ey/nnKmvCkb3UcMGBVzGS7E8MbtWW+7PLuP o2NNUaJS6sOxEd1Ocn0Dbkw= X-Google-Smtp-Source: ABdhPJxZ5NJmXTir0dR0oc59iufj5jh8AQrjcgvx1slO89GEuuBOTIYvO99vzrJSWwuLicOrrOWe+A== X-Received: by 2002:a05:6512:3da3:: with SMTP id k35mr1558110lfv.137.1633573660017; Wed, 06 Oct 2021 19:27:40 -0700 (PDT) Original-Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id m6sm269156lfb.190.2021.10.06.19.27.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 19:27:39 -0700 (PDT) In-Reply-To: <7814d113-5366-8614-8f5b-699800c303eb@gmail.com> 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:216602 Archived-At: On 06.10.2021 17:09, Nikolay Kudryavtsev wrote: >> But when we go up a directory, "./project/". And when asked to list >> its files, how do we avoid including "./project/foo/a" in that list? >> It would make sense to exclude any nested projects, right? > Not necessarily. It may be a useful thing to do for some projects, but > it does not follow from anything that it should be the only or the > default option. When should we not do it? > The correct solution here is IMHO implementing some kind > of .project-settings.el file in which you can set > hide-nested-project-files. You can already specify ignored files in a project through .dir-locals.el. But then you will end up specifying the same information twice. Once when setting up those new backends -- and the second time when configuring the parent project to ignore particular subdirectories. And that seems problematic from the usability standpoint. Also, that information can easily get out of sync. >> Setting project-find-functions in a major mode is a questionable thing >> to do, because then you end up with Emacs where files in the same >> directory belong to different projects. > I'm not talking about setting it locally in the mode, more about modes > providing such functions on load. That's another important question. > More backends are more functions to test, so it's reasonable to add > backends only when they're needed. I may avoid programming in language X > from some months so no reason to keep that backed on, but when I start > editing a file in that language, the major mode loads and so should the > backend. If the only piece of information such modes intend to provide is the name, or multiple names, of "marker" files which indicate that their containing directory is the root, and if this information should be applied by the user manually anyway, why not have a single backend for that purpose, with a custom var containing the list of files names? The major modes can tell the users to modify that variable. And this backend is in the proposed 'fallback' backend. >> If there is a next backend which indicates the same root, why do we >> need the first one? > We don't know what the next backend in line indicates. Nor do we care > about it since the current one already gives us something. We just try > to find backends until we find one in the order of priority and then stop. That didn't really answer my question. >> Suppose I call project-find-file, meaning to jump to another file in >> the same Git repository. And instead I am shown only a list of files >> in the current subdirectory because it contains, say, a Makefile. Is >> that a good idea to enact this kind of behavior automatically? > If a user believes that it looks like a duck, it should squeak like one. > Sure you personally may want to suppress some possible project backends > from firing, but someone may want the opposite. I'm not sure how I would suppress "possible project backends" from firing. That's the rub: the configuration is global, and whatever backend ends up being used, should be the most fitting to the total set of possible user's needs. Meaning, it should correspond to the user's view of the project to the best possible ability: point out the root, exclude the files that need to be excluded, and ideally fetch the list of files quickly as well. > I want to remind you of this recent-ish thread on HGE: > > https://lists.gnu.org/archive/html/help-gnu-emacs/2021-09/msg00045.html > > Lets take the maven example presented there. We have a project > containing modules. The user wants to compile both independently. We can > write two different compilation commands, one that works on the project > and one that works on the module. Or we can just have a single command, > since the compilation process is not different in any way for both. Then > we can give that command some prefix that would make it work not on the > project itself but on the root project of that project. Either you have a compilation command that is Maven-aware (and thus can find the module root directory on its own), or we add an extension of the project API, with generic like project-modules, where modules behave like projects themselves (can implement the 'root' and 'files' methods). And maybe with a project-current-module generic as well, though it could easily be implemented with a linear search across a small list (with file-in-directory-p check). But if the command creates a Maven-specific invocation, it doesn't need the above abstraction -- it works with Maven, so it knows Maven, it can look for the current module directly. Or just use the project root, if the appropriate value of prefix was specified. I don't see where your approach would make things simpler/more predictable/reliable. > The Makefile example is your strongest argument here, but we can define > find functions for it recursively. That is until you find a Makefile > that does not have a dominating Makefile of it's own. And if all else > fails you can just use the proposed plain project mark. That's possible, but it's not at all a guarantee that in every big project every Makefile will have a "dominating" Makefile of its own. The above is just a particular GNU convention. But Makefiles are also used for quick scripting in projects that are actually built with other tools. >> What user-level commands are going to benefit from this setup? > It seems that we somewhat differ in our priorities for project > treatment. You seem to prioritize the logical grouping of files for > editing operations, while I prioritize "actionability". I'm prioritizing "universality", so to speak. And predictability. So that a certain class of commands (or several classes, actually) can use "current project" and be reliably certain of what it is. > If a certain > directory has a set of unique actions that can be performed on it, then > it's a project for me. It would seem like your vision of the project could benefit from a notion like "facet". E.g. a project lookup would search for not just "the current project", but "the current build project" or "current file listing project", or... I don't know what else, actually. But I'm sure there can be other additions (something test-framework related, maybe). But unless I'm missing something major, the same goal could be served by an addition of a new hook. Like 'buildtool-find-functions'. Which would return, for example, new kind of object, and that object could tell the parent directory of its build file, and the list of the tasks described in it, and... perhaps something about how those tasks should be invoked. That new abstraction could be used by commands that want to interact with build files in an abstract fashion and to launch build tasks. It might also have a problem choosing which Makefile to use, out of a hierarchy of Makefiles, though. Requiring similar customization capability. > And while your observation that such emphasis on > actionability may result in worse logical grouping is broadly true, it > is not necessarily true that a blind reliance on VC backend would result > in proper logical grouping. Sure, that would be true for most projects, > but oftentimes you have multiple independent, but related projects > sharing the same repository. There are two patches in this bug report. Have you looked at the other one?