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: Mon, 29 Jun 2020 17:50:52 +0300 Message-ID: <83mu4m0vub.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> <83wo42w83e.fsf@gnu.org> <6762abf5-71c1-aa54-1bac-d4c90c20870b@yandex.ru> <831rmavsuq.fsf@gnu.org> <83a70wv4mj.fsf@gnu.org> <5542db0c-cc0d-2743-87ae-7728a0cc94bb@yandex.ru> <83ftaf2rj2.fsf@gnu.org> <43a8f8d4-83fb-f012-8e1d-c1a618b0ef59@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="109750"; 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 Mon Jun 29 16:51:43 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 1jpv8H-000SRJ-RH for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Jun 2020 16:51:41 +0200 Original-Received: from localhost ([::1]:41276 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jpv8G-00036k-TN for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Jun 2020 10:51:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51754) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jpv7g-0002eB-SQ for emacs-devel@gnu.org; Mon, 29 Jun 2020 10:51:04 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60818) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jpv7g-0002y9-48; Mon, 29 Jun 2020 10:51:04 -0400 Original-Received: from [176.228.60.248] (port=4676 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jpv7f-0000vi-5G; Mon, 29 Jun 2020 10:51:03 -0400 In-Reply-To: <43a8f8d4-83fb-f012-8e1d-c1a618b0ef59@yandex.ru> (message from Dmitry Gutov on Mon, 29 Jun 2020 01:35:19 +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:252565 Archived-At: > Cc: theo@thornhill.no, philip@warpmail.net, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Mon, 29 Jun 2020 01:35:19 +0300 > > >> Not to discourage alternative workflows, but this is the concept we > >> should work on supporting well first. > > > > What do you mean "first"? > > Meaning, I have to prioritize the tasks in my personal queue. And there > are other features I should get to as well. I hope you'll like them > either way. I didn't mean to ask you to change your priorities. I was only talking about the design of deciding what buffers belong to which project, and the implications of that design. > I think it's an objective summary. Because you said that not having this > capability keeps Emacs at a severe disadvantage to other editors. So it > was clearly a subject that required analysis. Once again, my problem is not with the schedule of providing the support for the use case I described, but with the current design which AFAICT makes it hard to add such support in the future. We should modify the design to make such use cases easier to add. > The model that other editors use, and the one I'm assuming you do as > well (guessing mostly due to how tags' UI works), is that you work only > on one "project" (in your sense of the word) at a time. > > Then, would I be correct to assume that if there exists a Grep buffer in > the current session, then it mostly likely belongs to the current > "project"? If so, would there be any particular advantage to using > project-switch-to-buffer instead of plain switch-to-buffer? No and no. My Emacs sessions run for many days on end, and during that time I work on several projects. Sometimes I need to switch between them every few minutes (e.g., when I read my email and need to answer questions and request, or review code, related to several projects, in the order in which I read the incoming email). More often, I would work for several hours on one project, then switch to another, then to yet another or back to the first. When I do switch, I don't want to lose the "payload" of the project I switch from: its files, its Grep, XREF, and Compilation buffers, its documentation buffers, etc. -- because I know I will come back there in hours or days. This means each project should stay readily accessible, so that I could pick up where I left off. It is true that the last Grep buffer I created most probably belongs to the current project, but that doesn't mean I want to give up the previous Grep buffer -- I might need it shortly. > I never said that it's an ideal method. And I'm sure there can be > problematic examples out there. But I wasn't convinced by the example > you gave because the reason for why it was bad was based on your > understanding on the word "project", and not on mine. Thus, it's hard > for me to choose a good solution for the project backend which is based > on my understanding of the word "project". I'm not asking you to come up with a backend suitable for the use case I described. I'm asking you to take that use case into consideration when you design the means of deciding which buffer belongs to what project. If we design this decision in a way that cannot be easily extended to reasonable use cases we can envision, we will limit ourselves in the use cases we can usefully support, ever. Let's try to avoid producing such a restrictive design, if we can. I can understand why some design might not be conducive to supporting use cases we never thought could be relevant. But this use case we already envision, and unless you really think it's completely not relevant, the design should IMO be able to support it easily enough.