From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: master 1e3b0f2: Improve doc strings of project.el Date: Sat, 20 Jun 2020 14:25:50 +0300 Message-ID: <6762abf5-71c1-aa54-1bac-d4c90c20870b@yandex.ru> References: <87bllfqj82.fsf@warpmail.net> <83o8pfxhzq.fsf@gnu.org> <83imfnxgt3.fsf@gnu.org> <626efe11-0f9c-081b-11dd-0d61cee8168d@yandex.ru> <83h7v7xf7w.fsf@gnu.org> <831rmayj55.fsf@gnu.org> <6dc2c2ac-8e17-f044-dc78-8c109f936ad2@yandex.ru> <83wo42w83e.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="95391"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Cc: philip@warpmail.net, theo@thornhill.no, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 20 13:26:38 2020 Return-path: Envelope-to: ged-emacs-devel@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 1jmbdu-000Oj5-Fu for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 13:26:38 +0200 Original-Received: from localhost ([::1]:58814 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmbdt-0004HE-Gm for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 07:26:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51650) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmbdG-0003pq-1g for emacs-devel@gnu.org; Sat, 20 Jun 2020 07:25:58 -0400 Original-Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]:40145) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jmbdD-0001HP-JA; Sat, 20 Jun 2020 07:25:57 -0400 Original-Received: by mail-wm1-x32b.google.com with SMTP id r15so11281804wmh.5; Sat, 20 Jun 2020 04:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gZ7O+cZU9Jg+DVNakmwj2sei5iKOwAT/OtRYdCr9LrE=; b=JWjlPHwL9JhLuItx/WC4I79JgyD+BsAXPdyEEo/8dTTm260So9rLEyQudYl8vxObUq QiQ1FMFvAzwmo9IAdRtPFLFw05A1yogOjIZHT2Xfc84eS/4igsoRpmqcoB3dUc/fboug opbA6h0HAcED7FxtwR+Z7mDyVloctT/OyxS2h+1mbI1p7IbNW8a8+Q8Qld6dNZnQ39LU D8APTJR3Cxem4w2LBw/HQo2jq5jB/wLynGbgikeiT1FR9PDG2U/o9PHV/MYQExGAcFXg p/nbthL9d3dzGge0VRHnGczJLS83su2oLgYLqp5aF2MCGF9dH5yDpkqetl64JrNTgmx4 OPoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=gZ7O+cZU9Jg+DVNakmwj2sei5iKOwAT/OtRYdCr9LrE=; b=k/V5d3u4WJJezKVepOyg6St2agdxiPMh/iISl1psUYQV99/eG0psBcuewx2MIirvAD 2quXOl+AxRUgIXLZHPl1TCsX7JosOzvxwgE8F0uAhKw83OqZ8dIeLqamcH3qO90ep/kK xfk2ZjIOd6LIhZzrShCXkKttDJvPRG4QXsfNLdEKsrPblNwfurswBFJsjAVS8BtKjdMo ESuqh5EAp+V/SKXhPJ7RHPAsg80JyjOjNofmH+E52Lt9OnymuVi37FJ2BJvTj4LxnfT9 lDkTy+MnuyxVVYxWAcOHXlMPkhDBCLPamx77RVbYjzjrA6/i5mZOo2+8eAx4t+FXwJfS DisQ== X-Gm-Message-State: AOAM530gujgbkEs/HUNPQwel4UbXy7s2DdsL/f1SQSEPWPw9WUfEvU+6 Q63p4pJTyDkYPrkmB/2s2zs5BVJr X-Google-Smtp-Source: ABdhPJx3YGFG+RQIZ7mUSH74an8Iv7Q8dNCwLDqUAbqj6MhZg6lamvgnrM8k2FBAuB4K8o0DVhEcUA== X-Received: by 2002:a1c:9687:: with SMTP id y129mr8294328wmd.30.1592652352762; Sat, 20 Jun 2020 04:25:52 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id y196sm4580512wmd.11.2020.06.20.04.25.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 20 Jun 2020 04:25:52 -0700 (PDT) In-Reply-To: <83wo42w83e.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::32b; envelope-from=raaahh@gmail.com; helo=mail-wm1-x32b.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: 0 X-Spam_score: 0.0 X-Spam_bar: / X-Spam_report: (0.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=1, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:252429 Archived-At: On 20.06.2020 09:43, Eli Zaretskii wrote: > So all you want to add to the current doc string is "...and doesn't > belong to some other project"? I don't know about that. Interpreting that literally would mean that such buffers would never be suggested because they "belong to some other project" (according to the reasoning which gave rise to this wording) no matter which of the projects is the current one: "the outer", or "the inner". So what we should say is just "belongs to the current project". The implication being that if it's inside a nested project, it doesn't belong to the outer one. >>> But the default-directory of these buffers is a very weak evidence of >>> them being relevant to some project. E.g., I could (and many times >>> do) grep some other project when I need to see how it solves some >>> problem which is relevant to what I'm working on now. >> >> That is a case of working on multiple projects at once. > > No, it isn't. I'm working on a single project, but need to look > outside of its directory to find some information. A very natural > thing to do, and it doesn't mean I started working on another > project. More importantly, I do want that Grep buffer be available to > me as part of the current project, because I'm likely to return there > more than once. And bookmarks/switch-to-buffer/registers are not good options for this goal? >> And whatever your purpose of grepping it, wouldn't you agree that >> that grep buffer is probably closer to the "other" project rather >> that to the current one? > > No. And that "other" project doesn't even have to be a "project" in > the project.el sense of the word. Here's one direction how it could be resolved: Make sure project-vc-external-roots-function points to a function that returns a list which includes the "other" directory. By default, it will include the directories where tags tables reside. Then create a new command, project-or-external-switch-to-buffer. Which would check for default-directory belonging not only to the project root, but for belonging the external roots as well. >> To reuse your argument, 'M-x switch-to-buffer' is still available for >> borderline cases. > > An argument that you dismissed previously. I dismissed it as in "people wanted to call this command less". But my specific wording also made provision for it being necessary at least sometimes. But you made this argument. So perhaps it may be good enough for your purposes. Am I wrong here? I don't want to dismiss your request outright, but we'll need to have some design which would fit the existing model and/or wouldn't be hard to support. Because exceptions and edge cases tend to pile up, if we just start adding exceptions here and there. > I think that non file-visiting buffers are rarely related to a > project, an exception rather than a rule. My suggestion is therefore > to turn the table and come up with a list of such buffers that > _always_ are related to a specific project. And instead of using the > default-directory as evidence for the buffer's relevance, we may need > a command that explicitly makes a buffer related to a project. Well, Phil gave a list of examples. And in all of those cases, I think, default-directory worked well as an indicator. In my work, having Grep buffer's default-directory belong to the current project is also a string indicator. >> So default-directory is not the worst indicator. > > I'm saying it isn't the best, either. We have just discovered at > least 2 problems with it. We should try to find a better one. One might interpret your request essentially as "I want any buffer, arbitrarily, based on my current intention, be associated with the current project". It's probably not as arbitrary, so you're welcome to suggest an alternative indicator. >> But we should also try the new command out and document our experiences. > > IMNSHO, some thought is required even before we hope the experience > will teach us in due time. Doing this only by trial and error runs > the risk of converging on a design that is found later to be > restrictive, or one that cannot be easily extended to support > behaviors not accounted for or envisioned originally. I'm not suggesting trying it for a few years. The command is here already, so the process has started. >> So far Theodor agreed too. And myself as well. You alone have voiced >> disagreement. With this distribution of votes, it seems the default >> behavior should default to including non-file-visiting buffers (with >> some agreed-upon exceptions). > > For an opinion to "count", it doesn't have to _replace_ the other > opinions. It could be taken into consideration by augmenting the > design so that it supports both kinds of behaviors. This is IME > better than flatly discarding the dissenting opinions. Sure. >> And, of course, we can add a user option that would allow to tweak >> the choosing logic. > > Sub-optimal selection of the "belongs to a project" criteria will make > any such user options cumbersome and hard to use. IOW, user options > shouldn't be considered as means to "fix" sub-optimal design. We are > at a point where we can make the design better, if we consider a wider > variety of project-related activities. Also agree.