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: Sun, 05 Jul 2020 17:26:03 +0300 Message-ID: <83imf2t4w4.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> <83mu4fvjh3.fsf@gnu.org> <7c2e93d4-8d86-bbbb-77a0-bf5d73051907@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8011"; 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 Sun Jul 05 16:26:30 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 1js5bC-00020K-3X for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Jul 2020 16:26:30 +0200 Original-Received: from localhost ([::1]:56862 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1js5bB-0006Ff-62 for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Jul 2020 10:26:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59436) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1js5aj-0005r2-Og for emacs-devel@gnu.org; Sun, 05 Jul 2020 10:26:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:33367) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1js5ai-0004mw-8d; Sun, 05 Jul 2020 10:26:00 -0400 Original-Received: from [176.228.60.248] (port=1225 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1js5ah-0000Ll-JE; Sun, 05 Jul 2020 10:26:00 -0400 In-Reply-To: <7c2e93d4-8d86-bbbb-77a0-bf5d73051907@yandex.ru> (message from Dmitry Gutov on Sun, 5 Jul 2020 01:22:50 +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:252696 Archived-At: > Cc: theo@thornhill.no, philip@warpmail.net, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sun, 5 Jul 2020 01:22:50 +0300 > > > 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? > > You mean like caching the return value of 'project-current'? Something like that, yes. > The problems I can see with that are: > > - Since project is not a minor mode, we don't call it in major mode > hooks. Which, by itself, is probably a good thing (causing no > unnecessary work/slowdown). But that means that in the middle of any > session we could have 100s of buffers that don't have any cached project > value. We have project-find-file and other similar project-* commands that could cache that as side effect. > - A project configuration can change mid-session (due to a customization > of some user option, or due to an edit in some .dir-locals.el). Or > simply due to 'git init'. As a result, a given file's current project > can change. It will be good to be able to support that without > necessitating Emacs' restart or requiring manual cache invalidation. I don't see how you can avoid some user command which would mean a project configuration change. Alternatively, this could be solved lazily, when the cached value is found to be outdated. We don't need to solve every possible complication up front before we decide that a method is workable, we just need to have a vague idea how it could be solved when the time comes. > > project-vc could then store the list of files in the project to serve > > the request, > > Store like cache the return value of 'project-files'? Still the same > issue with cache invalidation, described above. > > > or a directory if all the files in the directory belong > > to the project. > > The problem is in the case of *nested* projects. The first part above should take care of that. The second part was to suggest a shortcut: let a directory stand for all the files in it. > >> 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? > > Andrii's (and others') workflow implies more frequent switching between > "projects", rather than working on a single one for a long time. I don't see how that matters. We cannot/shouldn't prefer some valid workflows to other valid workflows, we should try supporting all the reasonable ones. > So we can go ahead with idea #1 (which implies no hard change to the > API) and see how far we can get push this idea without manual cache > invalidation, while keeping decent performance for most of our users. OK.