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 16:41:23 +0300 Message-ID: <966ef00b-fc7a-cd52-5fd8-600842797f65@yandex.ru> 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> <87zgrq2ctj.fsf@mail.linkov.net> <7cf254bf-a7e4-0121-3d0c-3a1b5dfabe0b@yandex.ru> <87r1d0at40.fsf@mail.linkov.net> <87wnmr793j.fsf@mail.linkov.net> <878rz6wrdp.fsf@mail.linkov.net> <9a74b6ac-14f4-c5f9-8d7e-91c1595d8a02@yandex.ru> <87wnmppdmr.fsf@mail.linkov.net> 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="37299"; 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 , Lars Ingebrigtsen , Theodor Thornhill , 41572@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 07 15:48:09 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 1mYTkn-0009Yk-9s for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Oct 2021 15:48:09 +0200 Original-Received: from localhost ([::1]:43432 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYTkm-0007fX-8S for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Oct 2021 09:48:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37492) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYTes-0000s3-Q1 for bug-gnu-emacs@gnu.org; Thu, 07 Oct 2021 09:42:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34919) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mYTes-0003E0-HA for bug-gnu-emacs@gnu.org; Thu, 07 Oct 2021 09:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mYTes-0002KG-EY for bug-gnu-emacs@gnu.org; Thu, 07 Oct 2021 09:42: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: Thu, 07 Oct 2021 13:42: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.16336141028912 (code B ref 41572); Thu, 07 Oct 2021 13:42:02 +0000 Original-Received: (at 41572) by debbugs.gnu.org; 7 Oct 2021 13:41:42 +0000 Original-Received: from localhost ([127.0.0.1]:46465 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYTeX-0002Jg-W5 for submit@debbugs.gnu.org; Thu, 07 Oct 2021 09:41:42 -0400 Original-Received: from mail-lf1-f53.google.com ([209.85.167.53]:39903) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mYTeU-0002JS-9U for 41572@debbugs.gnu.org; Thu, 07 Oct 2021 09:41:40 -0400 Original-Received: by mail-lf1-f53.google.com with SMTP id n8so24010626lfk.6 for <41572@debbugs.gnu.org>; Thu, 07 Oct 2021 06:41:38 -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=D7CPLNB+cWEUx41i72Sd08ZbSYZlc95gSkXaTyZrqK4=; b=iOffxm0yJn3DbRhHAcveje+UdCaQHb5pQo1k5KaqGlzlaET5b3csatLL1utUh7NBGe 9jrtrjcHkfAHHpVjonMRHx5UVZInrLN6ifOEqqchHv6TTG5QvpvuuzDZefReh3OXbiCJ XXNP24gmM9jZskcDG1/350qTYwyoCtlGOS8UDplhBtbql0CvZjNddLvPBKx4H/Pb328W A4jiWoaBb892ro6QCt+b6ewvTVjXM3X4MKmJi6cRnP7zRIKGahiGfmTCj4CkAAfCOuT0 Its/a4VDvDqPJdGzMlQA4lmaoqvHo3iiUG426mmpZ7Rov3pk646K9vdj+aBgHu2mEnoe akZg== 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=D7CPLNB+cWEUx41i72Sd08ZbSYZlc95gSkXaTyZrqK4=; b=gxuVx7RZsrW3uEGx/fjeW/XmG0IyZx4+JMMUHHpU/XOxUkZsjBekAQSDJo74K/gg7O TFtft9Us1b9K6kr6irYXiCYjtJV527tX6zF2ajAjRi49PJlfPgZkB5mcFhymxd6qEUOg fBNg0NPlDYgAngrCBaatEkcpnmkTxZiuwj6h5go8wHXAvlKiuwkT1I3GerkF1OSzRhSv 95VPw82IiqrllrKSMCqHtoyj9uwWrsvZhuRtPtJhVP+HrHPCt0J9FI8UKKTLIL2/l0NW LG8Dd+JDjEkA7HT0WQ5xAbcnv79Ure+cjYP1mSftLU1wTb1BqErVrZdpwCL+Tv8f07/z BFhw== X-Gm-Message-State: AOAM530R0amIWRlQC53E8rFWynt6MDyQti3yJId0Zv1ujw3P6u7b/IHN 2HvwF/jOmRX4VRs4A6KIJYsgcwWmUIk= X-Google-Smtp-Source: ABdhPJxYtZ6lUZeC96pQtdmYmuH4TnPMxsFAXmvz3mRg/u3o2Ex9ivcUQFAq12ZqJ31vhuRHsIsQ5w== X-Received: by 2002:ac2:5fef:: with SMTP id s15mr4182390lfg.190.1633614084620; Thu, 07 Oct 2021 06:41:24 -0700 (PDT) Original-Received: from [192.168.1.113] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id s14sm62591lfr.40.2021.10.07.06.41.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Oct 2021 06:41:24 -0700 (PDT) In-Reply-To: <87wnmppdmr.fsf@mail.linkov.net> 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:216665 Archived-At: On 07.10.2021 10:17, Juri Linkov wrote: >>> Maybe a better name would be 'project-directory-ignores' >>> with the directory-based backend name 'project-directory'? >> >> I don't know if it's better. What does "directory" mean? Every backend, >> every project has directories. > > Then maybe the backend could be named 'project-file' > since a special file defines the project root. That's a little more meaningful, though too close to 'project-files'. 'project-markered' or 'project-markerfile' would probably be less ambiguous. But... (*) >> As mentioned previously, the other option I had considered was 'novc'. Then >> the variable would be called project-novc-ignores. > > "novc" is the worst variant. It's not obvious that it means > "no-version-control", and also will make no sense when more backends > will be added. Might not be obvious, but when you know what 'vc' stands for, 'novc' should at least be a strong hint. And then you could reach for documentation. But indeed it's very short and might make less sense if more backends are configured. > Or no more backends are planned, and all other possible > roots should be handled by the same fallback backend? Or would it be > possible that more backends could be added in project-find-functions > after the file-based fallback backend? Then the name "fallback" > will make no sense if it will not be the last in project-find-functions. I don't know about the case of adding more backends at the end of project-find-functions (are there any people who have done this?), but otherwise, 'fallback' is both an indication that the backend is at the end, and a strong hint to avoid moving it to the front. Suppose somebody puts it before 'vc' to use if for a purpose we did not design it for: make sure that some subproject 'foo' in their monorepo is considered a separate project. 'foo/Makefile' exists, so they add "Makefile" to project-fallback-markers, and it kind of seems to work. But! File listing performance becomes worse: we didn't optimize this backend for use inside of (e.g.) Git repositories, we don't take advantage of 'git ls-files'. More than that, it doesn't honor the ignore instructions from .gitignore. Whereas, in a lot of cases, it would be helpful (and even necessary for good performance) to honor them. But on the other hand, why would a 'project-fallback', or 'project-file', or 'project-markerfile', honor .gitignore contents? Semantically, that doesn't make much sense. And yet, I'd wager like a half of the users would implicitly expect it to do so, and another half -- would not. That's doesn't seem like a great design. >> This is not a done deal, just what seems the most optimal to me at the >> moment. But opinions welcome. > > Maybe it will help to choose a better name while thinking about > more possible backends that could be added later. (*) ...it doesn't seem compatible with being used in arbitrary order with arbitrary backends. Perhaps, if we change our mind on the overall design later, we could create a new backend, with a different name and more complex implementation logic.