[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: Fri, 19 Jun 2020 22:28:39 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 19.06.2020 22:01, Eli Zaretskii wrote:

But it's an edge case. So we could take your description now. But we'd
need to change it when/if that edge case is fixed. The fix isn't
difficult, I'm just unsure about its performance characteristics.

I'm not sure that the doc string will have to be changed (or how) when
you fix that, but that's a separate issue.

The fix would look like this:

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 89dcee97fa..d4eab9cd58 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -777,7 +777,7 @@ project-compile
 (defun project-switch-to-buffer ()
   "Switch to a buffer in the current project."
-  (let* ((root (project-root (project-current t)))
+  (let* ((project (project-current t))
          (current-buffer (current-buffer))
          (other-buffer (other-buffer current-buffer))
          (other-name (buffer-name other-buffer))
@@ -785,9 +785,13 @@ project-switch-to-buffer
           (lambda (buffer)
             ;; BUFFER is an entry (BUF-NAME . BUF-OBJ) of Vbuffer_alist.
             (and (not (eq (cdr buffer) current-buffer))
-                 (when-let ((file (buffer-local-value 'default-directory
-                                                      (cdr buffer))))
-                   (file-in-directory-p file root))))))
+                 (cdr buffer)
+                 (when-let ((other-pr
+                             (project-current
+                              nil
+                              (buffer-local-value 'default-directory
+                                                  (cdr buffer)))))
+                   (equal project other-pr))))))
       "Switch to buffer: "

It's reasonably fast here when there are not many open buffers, but I fear the accuracy improvement from it might not outweigh the performance problems that will come up in the case of a lot of buffers.

There can be a different approach, though. To define a new generic like project-contains-p.

Not really. In most of these cases, such a buffer shows results
pertaining to a specific project, so its contents are basically
irrelevant when a user is working on a different one.

But the default-directory of these buffers is a very weak evidence of
them being relevant to some project.  E.g., I could (and many times
do) grep some other project when I need to see how it solves some
problem which is relevant to what I'm working on now.

That is a case of working on multiple projects at once. And whatever your purpose of grepping it, wouldn't you agree that that grep buffer is probably closer to the "other" project rather that to the current one?

To reuse your argument, 'M-x switch-to-buffer' is still available for borderline cases.

If we really
want to record in these buffers what project they are related to, we
need to have stronger evidence, like what was the current-buffer when
the command was invoked, or maybe something else (like name the
buffers in some special way).

We would start with strong counter-examples.

Generally, though, new buffers inherit default-directory from the buffers that created them. So default-directory is not the worst indicator.

Occur can be an exception because multi-occur can work across buffer
(and thus, projects). Help buffers contain history, so they are special
too. But the rest usually fall in with that rule.

"The rest" are a legion.  I suspect that many/most of them are like
Occur and Help.  We should audit them before we make such far-reaching
conclusions (unless someone already did).

I think some people here already have some experience working with Projectile and its projectile-switch-to-buffer, which exposes the current behavior by default.

But we should also try the new command out and document our experiences.

project-switch-to-buffer should be more helpful by offering
only "useful" buffers.

That is indeed an option, but Andrii requested a different behavior.

That's fine, but Andrii's opinion is not the only one that counts, is
it?  We are talking about a general-purpose Emacs feature, not about a
command that will only be used by a single person.  It should make
sense to all of us.

So far Theodor agreed too. And myself as well. You alone have voiced disagreement. With this distribution of votes, it seems the default behavior should default to including non-file-visiting buffers (with some agreed-upon exceptions). And, of course, we can add a user option that would allow to tweak the choosing logic.

reply via email to

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