[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 1e3b0f2: Improve doc strings of project.el

From: Dmitry Gutov
Subject: Re: master 1e3b0f2: Improve doc strings of project.el
Date: Sun, 5 Jul 2020 01:22:50 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]