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: Wed, 6 Oct 2021 17:09:28 +0300 Message-ID: <7814d113-5366-8614-8f5b-699800c303eb@gmail.com> References: <87ftb92u8q.fsf@thornhill.no> <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> 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="37254"; 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 Wed Oct 06 16:10:58 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 1mY7dJ-0009Qx-Ml for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Oct 2021 16:10:57 +0200 Original-Received: from localhost ([::1]:54868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mY7dI-0002mJ-Cn for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Oct 2021 10:10:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58346) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mY7cR-0002lC-V5 for bug-gnu-emacs@gnu.org; Wed, 06 Oct 2021 10:10:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33527) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mY7cR-0000MG-Mo for bug-gnu-emacs@gnu.org; Wed, 06 Oct 2021 10:10:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mY7cQ-0000xd-HB for bug-gnu-emacs@gnu.org; Wed, 06 Oct 2021 10:10: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: Wed, 06 Oct 2021 14:10: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.16335293843662 (code B ref 41572); Wed, 06 Oct 2021 14:10:02 +0000 Original-Received: (at 41572) by debbugs.gnu.org; 6 Oct 2021 14:09:44 +0000 Original-Received: from localhost ([127.0.0.1]:45073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mY7c7-0000x0-Mn for submit@debbugs.gnu.org; Wed, 06 Oct 2021 10:09:44 -0400 Original-Received: from mail-lf1-f46.google.com ([209.85.167.46]:33659) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mY7c5-0000wk-W4 for 41572@debbugs.gnu.org; Wed, 06 Oct 2021 10:09:42 -0400 Original-Received: by mail-lf1-f46.google.com with SMTP id y23so11302637lfb.0 for <41572@debbugs.gnu.org>; Wed, 06 Oct 2021 07:09:41 -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=Exr0oU1l6qjHOgZVkfrSOTdHe+MM/FA7VEk7qJ3O6Tw=; b=cl+C+0DT25kg2CjTPWUQmT4nq2PhlNFYRxdOJ3hsKnv0yvkw2O5jU/eZihqfO7E2zg JZI41t4sP/5EPa5h8MeLP24bYYPFB174o1fjBrlW0XNU26Dd2FQBgkmztmw9OXxEhne+ OtducdwHV4THrzPc+OwZUeFZsjX7h4EQmAnf9F6uBX7YQpGuWOzVVUuOfT1jGtfepIc9 rNFaoRm+tM6d6wQPxxvWsMZiKa1FaEsycQM5liPKhh3zUC+R1edIW68azquQ2s5fUPg/ oIKvwxujw4uMnD9h7L0lwDzM2fh5/Q9wEkepfqjn41y6TqdSgcPUgPH2GIShI/4DKpK4 oecA== 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=Exr0oU1l6qjHOgZVkfrSOTdHe+MM/FA7VEk7qJ3O6Tw=; b=sE4Lbl+Gc7d1+mYyAVRUTcMIwaxjVIpGJfkYKVIu8PaHm2dpZhT3cUz+VYnn8KP5FN l+MmEvJWIqopVWMgD79vRgRb79xzNFv987bcFUt1JKH3BKW7yrPb4YTXfK5A+CCUTQ52 kEhBHYEy3Hq5+TyE3ockGS9mv9zhFg4+57TMtlUbnJ6Q+pHwexCHAZVDs+tetj46MaUE ZjfQn1vc8TOBo7jcC4KymAYHtm01FwD15gIPyxihJ0AOxWKZ0h823HlXqUEnTcBN+GhC NFFH67I0nYKnlfX3IO9+Uo8yqS0HGNGQuCXiXWDSnftfOHACcuJsMuohfjLUGHzXIlCB F3+w== X-Gm-Message-State: AOAM532n5SrG+pXcXHd5gmayuWCYEpMKxDG02XTq5Dovy4WDaZTL5QZw MJIdXmlFOZx88TXs2UL33zU= X-Google-Smtp-Source: ABdhPJyweCIeJYy6VzcrObaON4H//GEPxuZ0b6/u4XYDhC5ThDHwpZgMaWstX5PRYcX0oaUeoY2TYw== X-Received: by 2002:a2e:2243:: with SMTP id i64mr28933246lji.333.1633529371604; Wed, 06 Oct 2021 07:09:31 -0700 (PDT) Original-Received: from [192.168.199.3] (broadband-46-242-10-137.ip.moscow.rt.ru. [46.242.10.137]) by smtp.gmail.com with ESMTPSA id e26sm496818ljg.13.2021.10.06.07.09.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 07:09:30 -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:216563 Archived-At: > 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. The correct solution here is IMHO implementing some kind of .project-settings.el file in which you can set hide-nested-project-files. > 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 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. > 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 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. 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. > 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". If a certain directory has a set of unique actions that can be performed on it, then it's a project for me. 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.