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: Fri, 8 Oct 2021 05:12:41 +0300 Message-ID: <50249566-fc74-bed1-6a7d-52acc3876187@yandex.ru> References: <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> <25a5eff6-3eed-92ad-7291-0b9c26f555c9@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="21755"; 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 Fri Oct 08 04:13:11 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 1mYfNn-0005UX-Ja for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 08 Oct 2021 04:13:11 +0200 Original-Received: from localhost ([::1]:45954 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYfNm-0005U4-37 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Oct 2021 22:13:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34608) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYfNf-0005Tw-4B for bug-gnu-emacs@gnu.org; Thu, 07 Oct 2021 22:13:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37193) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mYfNe-00056k-O3 for bug-gnu-emacs@gnu.org; Thu, 07 Oct 2021 22:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mYfNe-00079L-H8 for bug-gnu-emacs@gnu.org; Thu, 07 Oct 2021 22:13: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: Fri, 08 Oct 2021 02:13: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.163365917527471 (code B ref 41572); Fri, 08 Oct 2021 02:13:02 +0000 Original-Received: (at 41572) by debbugs.gnu.org; 8 Oct 2021 02:12:55 +0000 Original-Received: from localhost ([127.0.0.1]:48739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYfNW-00078z-Ka for submit@debbugs.gnu.org; Thu, 07 Oct 2021 22:12:55 -0400 Original-Received: from mail-lf1-f47.google.com ([209.85.167.47]:43706) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYfNR-00078e-N7 for 41572@debbugs.gnu.org; Thu, 07 Oct 2021 22:12:52 -0400 Original-Received: by mail-lf1-f47.google.com with SMTP id r19so31048785lfe.10 for <41572@debbugs.gnu.org>; Thu, 07 Oct 2021 19:12:49 -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=vRw3QTBKqZE06CFMSmlYB+KI0YmReSTMNUmTbEUTHyg=; b=qUwOLtEDJ65gaEukDrvvjJgflTOJIYG1/+1DPKV+JvilzAhYN+vl75rOdpYjSsorZn vuEZgn3V19Khz+25iqtxFJ1/Eb49lypp2Zz9b+VFOva3ZRlAw5H9mVmIXcsxX2fDCSQ7 /8AiHfP1ErnzxSRKyJ2o11EGYxkbunCDux1UqCpjDhw6DFj1tN9lJYj4hXJe68gyZb1u eCZzZBk1Gf14SfJKc5NoEESF1dxOlmPvJGcydrNZKgM9ogLvR5saWcTfpytuuJZ5Omdx FWqIMpRPCMe7JFwNJhXYtYS7hFfnkmy5So6KXBdYHSaUNqmQJO0pePsSVFYLVPlmZGTC DIig== 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=vRw3QTBKqZE06CFMSmlYB+KI0YmReSTMNUmTbEUTHyg=; b=DsFEBWdJMt5RjTnEXmGlWz0qtOikw1BxD1JnD9GDeDwz4HGlsN8mgT4N1VZEPJ7+aj X4MKxEddDzjL/tZCCrc/5DqM9ikv/m+9uIS0WNEaulwHCc4h5R5CkhFF7YldHMYJFCfN AnUSzistOtj9It/Tp5R2U46guWDpXa2Gy3oUMwS5w1+FWfNJAX60Z18+x7c59AIKg30a Kx4bazWZ2bkjhTgzWs3CnSlWTwM97y8OUMTFg6DUWT5SJ7FF4JwSE2ioazcqzoJjQ20i XWtoMTXJJbNjJipCp3tZfy51emYi33PzUb536nL4J3gXGZzlddu2RFHCDTOmcFsKEjpK R6dw== X-Gm-Message-State: AOAM533hZKxgiAPR48TWxdWpZgcPuUEJ56+158cLNX85WHUdu/tVNWxd umibBtpXQqLaebc/lE9zBwI= X-Google-Smtp-Source: ABdhPJwAVs27Yj2s/o3l8BNa8BzTMg+thi+xoQEv7m6OgkOPhmaUNyO9ugex+EEUoALpugbCm/d0SQ== X-Received: by 2002:ac2:5978:: with SMTP id h24mr7866296lfp.426.1633659163457; Thu, 07 Oct 2021 19:12:43 -0700 (PDT) Original-Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id z14sm124211lji.102.2021.10.07.19.12.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Oct 2021 19:12:42 -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:216692 Archived-At: On 07.10.2021 16:08, Nikolay Kudryavtsev wrote: >> When should we not do it? > Personal preference. I'd probably never hide subproject files in 99% of > the projects I work on. All right. So you might like the possible alternative approach to this problem. What's your stance of having "filemarker" projects honor (or not honor) .gitignore instructions from the containing VCS repo? >> 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. > You can have a `project-hide-nested-project-files' variable, set it once > for all backends. Maybe per backend version too. 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. >> why not have a single backend for that purpose, with a custom var >> containing the list of files names? > Right, so remember, I said we can use this to realize most of the > Projectile backends? Well, the ones we can't realize would require > regexps, usually of the "\\.ext$" kind. So you have to account for those > too. Then there may be some other possible cases requiring custom function. project-fallback-markers can easily support globs (I didn't add the support initially because the naive implementation of checking for files including globs is slower). Support for predicate functions among its entries is pretty trivial to do. OTOH, when we only have a list of project-finding functions (one per project marker, say), it's pretty difficult to find the deepest enclosing project directory without running them all, and having them traverse the parent directories up until /. This is an inevitably slow approach. Can be bearable in a local filesystem; might be fatal over Tramp. > Lets say I have this structure: VC root, subfolders containing multiple > related, but independent projects in some programming language, backend > for which exists; deeper in one of the subfolders I have a GTAGS file, > assume GTAGS backend exists in one form or another. GTAGS file is placed > in this location because elsewhere in the repo there are symbol names > that are too close to each other and it's more convenient not having > them show up when I lookup something. I don't want VC backend to define > the project root here for obvious reasons. The major mode build tool > backend should do OK and I may or may not want GTAGS to define the > project root. It doesn't seem like you want GTAGS to define project root; you'll only want certain commands, like xref-find-definitions, to use the closes GTAGS file. Good thing xref-find-definitions doesn't use the project.el infrastructure at all. > Having one find-function list which the user can reorder as he sees fit > and that list may contain not just filenames, but regexps and custom > functions too. I'm not seeing the concrete usage scenarios yet. > As for customizability: we're already discussing at least 2 backend > settings: hide-nested-project-files and recursivity. Those settings > require a backend to be something more than a filename string in a > secondary list. These settings, as I see it, will be on the project-vc backend. >> That didn't really answer my question. > All right, lets rephrase the answer. At the moment in time a backend is > defined we do not know every single exact situation that backend would > have to operate in, because that would require the ability to predict > time, which we technologically do not have at the current moment. Lets > say I add a backend for my major mode. Someone in exactly 18 days, 6 > hours, 5 minutes and 3 seconds decides to use it to work on his project. > Unfortunately I do not know whether his project is in VCd and if VC > project backend returns the same root. If I could predict time and my > prediction of all possible future use cases would show that VC backend > returns the same root for every single one of them, I of course would > not bother adding mine. But because my imperfect human understanding > makes me think that it won't, I have to add a backend of my own. Okay, but we need both correctness and speed. Answering "see if there is a fast backend behind this one with the same root" is not very useful, since in this scenario we seemingly (!) don't need the first backend anyway. But perhaps you meant we should always scan the full list of backends, and we should not only accept a "fast" backend with the same root, but with root in any parent directory as well. Which would correspond to the popular situation with the monorepo. Setting aside the performance concerns of always scanning for all backends in project-find-functions, what do we do with the ignore entries? A backend is (very roughly) defined as (root . ignores), to be able to only list and work with a subset of files from its root's directory tree. The VC backend traditionally includes .gitignore entries in its list of ignores. So its project-ignores method includes them, and its project-files method implicitly uses them. But what if your first detected backend has a different list of ignores configured? Or none? Do we account for the latter's (fast) backend ignores when asking it for the list of files in the first backend's detected root directory. In practical terms, as just one example, that would mean honoring .gitignore at the top of a monorepo. Which might seem like a good thing to do, but also a somewhat unexpected behavior, conceptually. > Probably the best route here globally, is changing > project-find-functions to a list with numerical priorities, so that you > could set VC backend to priority 0 in your init and instruct mode > developers to never put anything with the same priority or higher in the > docstring. That's quite easy to do already: project-find-functions is a hook, and 'add-hook' has a DEPTH argument. Since Emacs 27, I think. >> 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. > Yes, but we can define a list of possible parent backends for every > backend. For example you could set VC as possible parent backend for > Makefile. Would probably not be a good idea in general, but for your > VC-first workflow, should be fine. 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. >> 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). > Or a "module" right? I was thinking about this too, and could not find a > good name for it either. 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. > Such a solution would be a reliable working > compromise between our schools of thought. You get your project-root > untouched, I get my own project root to do whatever I please with it. > The problem with it is that it's really overengineered. For most > projects there would be a 1 to 1 relationship between the project and > the module(artifact?) and even if it's not 1 to 1, there's a root module > most of the time. That's why it feels inferior to me in comparison to > just treating everything as projects and going bottom up. I don't know if it's really overengineered, especially compared to certain proposals in your previous email. 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. Thanks for the reminder about that thread, BTW. Speaking of build tools -- just as well, if the tool is in the same directory as the project root, you don't need any additional backends. But if you do need extra detection, file-finding logic, that could be put into 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. > After studying Projectile build commands I found them inadequate, since > it provides just two, compile and build, while even my simple major mode > requires a separate debugging command too. 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. > This solution suffers from > the same lack of flexibility. Take for example unit testing. It's not > necessarily build tool subservient and can be independent from it, but > it is situated in relation to the build tool root. So what's the problem with this approach, then? The run-tests command can for example run the buildtool-find-functions, take the appropriate one, search its parent directory for the presence of testing frameworks, and launch it. > The maven hierarchy > is problematic for this too, while my "treat everything as projects" > paradigm has an elegant solution in which you can use a numerical prefix > to launch a build command on the Nth parent of the current project. It sounds like this approach, at the very least, doesn't go through 'project-current'? Are there other advantages, rather than being able to choose the project parent nesting depth with the prefix argument? >> There are two patches in this bug report. Have you looked at the other >> one? > You mean the original patch? Well it is IMHO better than yours since > it's less ambitious and does not go in what I believe to be the wrong > direction. The 'project-vc-subprojects' patch. Here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41572#85