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

[Dmitry Gutov]

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."
   (interactive)
-  (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
      (read-buffer
       "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.