[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: Thu, 2 Jul 2020 01:57:37 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

Hi Eli,

On 29.06.2020 17:50, Eli Zaretskii wrote:

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.

If you recall, I even posted a "more correct" patch a while back that wouldn't make the choice of which buffers belong to the project depend solely on the value of default-directory.

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.

...and I asked for design suggestions that would make the behavior better from your standpoint.

Some ideas, old and new:

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. 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.

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.

I see, thank you.

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 way, they wouldn't be "lost", but you'd have to deal with filtering through many buffers. Even so, Grep buffers are usually named uniquely, so it's unlikely to be a total disaster. And you wouldn't be able to clean then up easily with project-kill-buffers.

Anyway, I'm talking about the backup plan here. One to consider if we don't manage to settle on a better approach.

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.

Sure, agreed.

reply via email to

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