From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: master 1e3b0f2: Improve doc strings of project.el Date: Sun, 5 Jul 2020 01:22:50 +0300 Message-ID: <7c2e93d4-8d86-bbbb-77a0-bf5d73051907@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> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4836"; 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 Sun Jul 05 00:23: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 1jrqZO-0001AH-5C for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Jul 2020 00:23:38 +0200 Original-Received: from localhost ([::1]:54318 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jrqZN-0003VM-4o for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Jul 2020 18:23:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49194) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jrqYj-0002zU-B5 for emacs-devel@gnu.org; Sat, 04 Jul 2020 18:22:57 -0400 Original-Received: from mail-wr1-x442.google.com ([2a00:1450:4864:20::442]:41012) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jrqYh-0005VA-5i; Sat, 04 Jul 2020 18:22:57 -0400 Original-Received: by mail-wr1-x442.google.com with SMTP id z15so25369051wrl.8; Sat, 04 Jul 2020 15:22: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=icxJ1qnHuSBWzDXU36ens9mQICueWoQPCv4cff4FpvE=; b=C8S1mT/j8r8wmTrWUJgHiNbHR/DYSFqpSM/nc9qSZ1zu+tSQSQYV94solK/90DQH7H 5Nc2ECGfcVW/Gy7QQZTQjaHSN2hsvGoQl5wjYoDTHLzgOopp/1d/G+7mAdwkRWvyC/uE Ta4DuS1rU8WbcKFz8Zqn8p4VyIZtV10+6jcAx86oba/UyAWR84dbQuVRv02mOlxpYk74 u0xNHcn5Z4HDU1Pw9NA3BnmKzIruVvIvN9idD35XNYOW+ht/0x661Hqn1fhEme5O+Vtn aKgcmbxqGRYSg3rOEIdVlzkm+6EvtY/JmO/JAQpnjDTWdmeuirz5czLGlTCVKUa9QRZu tQVw== 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=icxJ1qnHuSBWzDXU36ens9mQICueWoQPCv4cff4FpvE=; b=ZNTPSp0NEddtyw4OtvO/lqHU4MKr2FGRuUlEBezXl8Vkqq4n0d7O9fBJw8pxFfYFrQ 7bGWoYzNjB7ZPqPqt5H4QjHCuIXFP5/LY/dnM68YVNLfgC3+AFMad0LS0UbKR5O4Ds2V ogMdZ9IgWdy3VdakRUkVfOtAKAedOyZN3AmiQympz+byhZemzHefwC7q6ohZ8e70mxFJ w34FTDnZhtCjE/KoAe4G6ZKl39bk2xMx6BFkOMdTBaGvpjEvHmmrKZaJmeGdaIZFWiBe sZfL6f+bD7JrBg6rrqCJeYsKtMu8byX1HPoQKkPQBGOdIML7FukqmOQQZ7lAQcborXDI fcpA== X-Gm-Message-State: AOAM533q5FkZhtsFb2rbxKDEWksPpwZsVYBkCHa9jLlkU+8VRfNOc/ha jTRnHPPpIchZSOed35ki2OCKNeTS X-Google-Smtp-Source: ABdhPJxTU3NKmg5W25ZBJki32dV9zx06PxY/3o9mRwnjOo/pKdUFMoSPjNkRgzBgyH9aHCl4GeHgMQ== X-Received: by 2002:a5d:5151:: with SMTP id u17mr11675038wrt.154.1593901372287; Sat, 04 Jul 2020 15:22:52 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id e4sm17784005wrt.97.2020.07.04.15.22.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Jul 2020 15:22:51 -0700 (PDT) In-Reply-To: <83mu4fvjh3.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::442; envelope-from=raaahh@gmail.com; helo=mail-wr1-x442.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:252681 Archived-At: On 04.07.2020 10:15, Eli Zaretskii wrote: >> ...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? You mean like caching the return value of 'project-current'? 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. Fetching the current project of all those at once could result in a long pause (some benchmarking on various machines/project configurations/sessioning habits would be welcome). - 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. >> 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, 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. That's the situation when all of the files belong to a directory _except_ those that belong to projects inside the current one. Like the monorepo example Theodor described. >>> 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? Andrii's (and others') workflow implies more frequent switching between "projects", rather than working on a single one for a long time. I would imagine that with such approach, using commands scoped to the current project's buffer would be more necessary. Having said all that, I've had a couple more ideas for transparent caching, such as caching by default-directory in the project-vc backend, and clearing the cache in post-command-hook. 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. N.B.: project-vc currently caches the "current project" info more persistently than would be ideal; a part of this experiment will be scaling back on that caching, and wait for complaints about performance.