From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master 1e3b0f2: Improve doc strings of project.el Date: Sat, 04 Jul 2020 10:15:52 +0300 Message-ID: <83mu4fvjh3.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> <83mu4m0vub.fsf@gnu.org> <44f2f1f4-ae34-f0bf-b153-f33b8ee6069f@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2734"; 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 Jul 04 09:16:55 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 1jrcPv-0000cB-RE for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Jul 2020 09:16:55 +0200 Original-Received: from localhost ([::1]:38972 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jrcPu-000151-Pf for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Jul 2020 03:16:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42768) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jrcOw-0000R6-5R for emacs-devel@gnu.org; Sat, 04 Jul 2020 03:15:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59496) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jrcOs-00021L-OM; Sat, 04 Jul 2020 03:15:51 -0400 Original-Received: from [176.228.60.248] (port=3788 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jrcOr-0005Nz-UD; Sat, 04 Jul 2020 03:15:50 -0400 In-Reply-To: <44f2f1f4-ae34-f0bf-b153-f33b8ee6069f@yandex.ru> (message from Dmitry Gutov on Thu, 2 Jul 2020 01:57:37 +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:252657 Archived-At: > Cc: theo@thornhill.no, philip@warpmail.net, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Thu, 2 Jul 2020 01:57:37 +0300 > > > 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. > > ...and I asked for design suggestions that would make the behavior > better from your standpoint. I proposed one: have a special per-buffer variable which will give the project (or a list of projects, if we want this to be more general) to which the buffer is related. I don't think we discussed that possibility in detail, did we? > 1. We can call 'project-current' in every buffer, and then compare the > returned values (this is what that alternative patch did). But recalling > bug#41029, it seems some users can have outstanding numbers of buffers > open, and this approach might heavily limit the performance of > project-switch-to-buffer, unless we employ some very heavy > buffer->project caching. And I'd really like to stay away from manual > cache invalidation. > > 2. We could call 'project-files' on the current project and compare the > values of buffer-file-name of every buffer. This could become slow with > larger projects. And the complexity will be N^2 (at least with naive > implementation), so it can be worse than project-find-file for those > projects. Also, this doesn't solve your problem with Grep buffers. But > it would help in the situation of having a project contain arbitrary > files from arbitrary directories. > > 3. Create a new generic function (or several) which would delegate the > inclusion logic to individual project backends. This would require work > on naming, semantics, what have you, and would likely still come out > clunkier than either of the previous two options. #3 sounds like the best alternative to me, if a simple buffer-local variable doesn't do the job for some reason. > Further, with this approach, I'm still not sure of a good "fast" > solution for project-vc which leads to correct behavior in the > presence of nested projects. project-vc could then store the list of files in the project to serve the request, or a directory if all the files in the directory belong to the project. > > 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. > > What I meant, would there be a lot of downside to using switch-to-buffer > specifically to switch to file-less buffers such as Grep when a need arises. This would mean we give up on supporting this use case by project commands, wouldn't it? Then I'd ask why this case is unsupported, while the one described by Andrii is? > Anyway, I'm talking about the backup plan here. One to consider if we > don't manage to settle on a better approach. Understood.