From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master 1e3b0f2: Improve doc strings of project.el Date: Sat, 20 Jun 2020 09:43:17 +0300 Message-ID: <83wo42w83e.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="122002"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philip@warpmail.net, theo@thornhill.no, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 20 08:44:16 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 1jmXEc-000VcZ-Lk for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 08:44:14 +0200 Original-Received: from localhost ([::1]:54534 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmXEb-0007qp-Ls for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 02:44:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59084) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmXDu-0007PN-V7 for emacs-devel@gnu.org; Sat, 20 Jun 2020 02:43:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35753) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmXDs-0008VP-Fo; Sat, 20 Jun 2020 02:43:28 -0400 Original-Received: from [176.228.60.248] (port=2848 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jmXDr-00078n-PN; Sat, 20 Jun 2020 02:43:28 -0400 In-Reply-To: <6dc2c2ac-8e17-f044-dc78-8c109f936ad2@yandex.ru> (message from Dmitry Gutov on Fri, 19 Jun 2020 22:28:39 +0300) 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:252420 Archived-At: > Cc: theo@thornhill.no, philip@warpmail.net, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Fri, 19 Jun 2020 22:28:39 +0300 > > > I'm not sure that the doc string will have to be changed (or how) when > > you fix that, but that's a separate issue. > > The fix would look like this: So all you want to add to the current doc string is "...and doesn't belong to some other project"? > > 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 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. > To reuse your argument, 'M-x switch-to-buffer' is still available for > borderline cases. An argument that you dismissed previously. > > If we really > > want to record in these buffers what project they are related to, we > > need to have stronger evidence, like what was the current-buffer when > > the command was invoked, or maybe something else (like name the > > buffers in some special way). > > We would start with strong counter-examples. I just gave you one. You want to dismiss it as "not strong", but I think you are making a mistake. Search-like activities are ubiquitous, and not confined to the project's directory tree. 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. > 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. > 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. We are just at the beginning of development here, and so this is the right place for thinking about possible project-related activities, and how they could be supported by different ways of determining which buffers are related to a project and which aren't. A simple solution we decide on now could make future development and extension much easier. > > That's fine, but Andrii's opinion is not the only one that counts, is > > it? > > 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. > 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.