From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: philip@warpmail.net, theo@thornhill.no, emacs-devel@gnu.org
Subject: Re: master 1e3b0f2: Improve doc strings of project.el
Date: Fri, 19 Jun 2020 22:28:39 +0300 [thread overview]
Message-ID: <6dc2c2ac-8e17-f044-dc78-8c109f936ad2@yandex.ru> (raw)
In-Reply-To: <831rmayj55.fsf@gnu.org>
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.
next prev parent reply other threads:[~2020-06-19 19:28 UTC|newest]
Thread overview: 149+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200619075401.21856.16524@vcs0.savannah.gnu.org>
[not found] ` <20200619075402.CE1D220A27@vcs0.savannah.gnu.org>
2020-06-19 11:01 ` master 1e3b0f2: Improve doc strings of project.el Dmitry Gutov
2020-06-19 11:24 ` Eli Zaretskii
2020-06-19 11:37 ` Basil L. Contovounesios
2020-06-19 11:50 ` Eli Zaretskii
2020-06-19 12:30 ` Dmitry Gutov
2020-06-19 12:44 ` Eli Zaretskii
2020-06-19 12:54 ` Dmitry Gutov
2020-06-19 13:27 ` Philip K.
2020-06-19 13:34 ` Dmitry Gutov
2020-06-19 14:11 ` Eli Zaretskii
2020-06-19 14:18 ` Dmitry Gutov
2020-06-19 14:24 ` Eli Zaretskii
2020-06-19 14:41 ` Philip K.
2020-06-20 7:22 ` Eli Zaretskii
2020-06-19 14:25 ` Theodor Thornhill
2020-06-19 14:37 ` Eli Zaretskii
2020-06-19 14:49 ` Dmitry Gutov
2020-06-19 15:11 ` Eli Zaretskii
2020-06-19 18:33 ` Dmitry Gutov
2020-06-19 19:01 ` Eli Zaretskii
2020-06-19 19:28 ` Dmitry Gutov [this message]
2020-06-20 6:43 ` Eli Zaretskii
2020-06-20 7:43 ` Theodor Thornhill
2020-06-20 8:55 ` Eli Zaretskii
2020-06-20 9:29 ` Theodor Thornhill
2020-06-20 10:07 ` Eli Zaretskii
2020-06-20 10:19 ` Theodor Thornhill
2020-06-20 11:37 ` Dmitry Gutov
2020-06-20 11:35 ` Dmitry Gutov
2020-06-20 12:32 ` Eli Zaretskii
2020-06-20 22:21 ` Dmitry Gutov
2020-06-20 11:29 ` Dmitry Gutov
2020-06-20 11:46 ` Kévin Le Gouguec
2020-06-20 11:57 ` Dmitry Gutov
2020-06-20 12:37 ` Eli Zaretskii
2020-06-20 21:18 ` Dmitry Gutov
2020-06-20 12:25 ` Eli Zaretskii
2020-06-20 23:17 ` Dmitry Gutov
2020-06-20 11:25 ` Dmitry Gutov
2020-06-20 12:12 ` Eli Zaretskii
2020-06-20 12:30 ` Basil L. Contovounesios
2020-06-20 12:42 ` Eli Zaretskii
2020-06-20 23:11 ` Dmitry Gutov
2020-06-21 15:08 ` Eli Zaretskii
2020-06-21 22:24 ` Juri Linkov
2020-06-22 2:27 ` Eli Zaretskii
2020-06-28 0:56 ` Dmitry Gutov
2020-06-28 14:28 ` Eli Zaretskii
2020-06-28 22:35 ` Dmitry Gutov
2020-06-29 14:50 ` Eli Zaretskii
2020-06-29 15:07 ` Stephen Leake
2020-06-29 22:35 ` Juri Linkov
2020-07-01 22:02 ` Dmitry Gutov
2020-07-01 22:07 ` Dmitry Gutov
2020-07-01 22:57 ` Dmitry Gutov
2020-07-04 7:15 ` Eli Zaretskii
2020-07-04 22:22 ` Dmitry Gutov
2020-07-05 14:26 ` Eli Zaretskii
2020-07-05 19:45 ` Dmitry Gutov
2020-07-07 15:04 ` Eli Zaretskii
2020-07-07 15:23 ` Dmitry Gutov
2020-07-10 14:27 ` Eli Zaretskii
2020-07-10 14:57 ` Dmitry Gutov
2020-07-10 18:14 ` Eli Zaretskii
2020-07-10 19:36 ` Dmitry Gutov
2020-07-11 6:58 ` Eli Zaretskii
2020-07-11 11:29 ` Dmitry Gutov
2020-07-11 12:35 ` Eli Zaretskii
2020-07-12 0:48 ` Dmitry Gutov
2020-07-12 14:00 ` Eli Zaretskii
2020-07-12 14:16 ` Dmitry Gutov
2020-07-12 14:47 ` Eli Zaretskii
2020-07-12 15:08 ` Dmitry Gutov
2020-07-12 15:36 ` Eli Zaretskii
2020-07-12 16:17 ` Eli Zaretskii
2020-07-13 1:51 ` Dmitry Gutov
2020-07-13 4:40 ` Eli Zaretskii
2020-07-13 7:11 ` Gregory Heytings via Emacs development discussions.
2020-07-13 7:21 ` Eli Zaretskii
2020-07-13 7:52 ` Gregory Heytings via Emacs development discussions.
2020-07-13 8:53 ` Eli Zaretskii
2020-07-13 18:26 ` Dmitry Gutov
2020-07-13 7:58 ` tomas
2020-07-17 10:27 ` Dmitry Gutov
2020-07-17 15:27 ` tomas
2020-07-18 0:55 ` Dmitry Gutov
2020-07-18 9:05 ` tomas
2020-07-18 10:10 ` Eli Zaretskii
2020-07-18 11:58 ` Dmitry Gutov
2020-07-18 19:14 ` Dmitry Gutov
2020-07-19 2:27 ` Richard Stallman
2020-07-19 21:59 ` Dmitry Gutov
2020-07-20 2:44 ` Richard Stallman
2020-07-13 19:51 ` Dmitry Gutov
2020-07-16 16:34 ` Eli Zaretskii
2020-07-16 18:55 ` Dmitry Gutov
2020-07-16 19:57 ` Eli Zaretskii
2020-07-16 21:02 ` Dmitry Gutov
2020-07-17 1:07 ` Richard Stallman
2020-07-17 1:30 ` Dmitry Gutov
2020-07-16 18:56 ` Dmitry Gutov
2020-07-16 19:59 ` Eli Zaretskii
2020-07-16 20:53 ` Dmitry Gutov
2020-07-13 2:51 ` Richard Stallman
2020-07-13 10:47 ` Dmitry Gutov
2020-07-13 13:00 ` Eli Zaretskii
2020-07-13 15:24 ` Dmitry Gutov
2020-07-13 16:30 ` Eli Zaretskii
2020-07-13 19:01 ` Dmitry Gutov
2020-07-13 19:41 ` Eli Zaretskii
2020-07-13 21:39 ` Dmitry Gutov
2020-07-11 12:59 ` Michael Albinus
2020-07-12 14:49 ` Dmitry Gutov
2020-07-12 17:19 ` Michael Albinus
2020-06-28 22:14 ` Dmitry Gutov
2020-06-29 14:32 ` Eli Zaretskii
2020-06-19 15:02 ` Dmitry Gutov
2020-06-19 15:13 ` Eli Zaretskii
2020-06-19 18:23 ` Dmitry Gutov
2020-06-19 18:44 ` Eli Zaretskii
2020-06-19 18:49 ` Dmitry Gutov
2020-06-19 19:07 ` Eli Zaretskii
2020-06-19 15:02 ` Theodor Thornhill via Emacs development discussions.
2020-06-19 15:19 ` Eli Zaretskii
2020-06-19 15:39 ` Theodor Thornhill
2020-06-19 17:11 ` Eli Zaretskii
2020-06-19 17:46 ` Theodor Thornhill
2020-06-19 18:03 ` Eli Zaretskii
2020-06-19 18:19 ` Dmitry Gutov
2020-06-19 18:36 ` Eli Zaretskii
2020-06-19 18:49 ` Dmitry Gutov
2020-06-19 18:22 ` Theodor Thornhill
2020-06-19 18:41 ` Eli Zaretskii
2020-06-19 18:57 ` Theodor Thornhill
2020-06-19 19:10 ` Dmitry Gutov
2020-06-19 20:08 ` theo
2020-06-19 19:04 ` Dmitry Gutov
2020-06-19 19:12 ` Eli Zaretskii
2020-06-19 19:33 ` Dmitry Gutov
2020-06-20 7:20 ` Eli Zaretskii
2020-06-20 11:41 ` Dmitry Gutov
2020-06-20 12:36 ` Eli Zaretskii
2020-06-20 21:58 ` Dmitry Gutov
2020-06-19 18:21 ` Dmitry Gutov
2020-06-19 18:30 ` Theodor Thornhill
2020-06-19 14:07 ` Eli Zaretskii
2020-06-19 14:23 ` Dmitry Gutov
2020-06-19 14:28 ` Eli Zaretskii
[not found] <<87bllfqj82.fsf@warpmail.net>
[not found] ` <<83o8pfxhzq.fsf@gnu.org>
[not found] ` <<I2nnldrvYQuQLpqgZyK7owqcMuP8kMtAdgkVXzq66i2hg6TgDaYFJe4RMj19j0J9Z1WqR9_vbifeegWNOLS3BBv-R34nJLuXYurqIVrefNE=@thornhill.no>
[not found] ` <<83imfnxgt3.fsf@gnu.org>
[not found] ` <<626efe11-0f9c-081b-11dd-0d61cee8168d@yandex.ru>
[not found] ` <<83h7v7xf7w.fsf@gnu.org>
[not found] ` <<b7f4a9ba-4320-b7b2-e150-74d667943ecd@yandex.ru>
[not found] ` <<831rmayj55.fsf@gnu.org>
[not found] ` <<6dc2c2ac-8e17-f044-dc78-8c109f936ad2@yandex.ru>
[not found] ` <<83wo42w83e.fsf@gnu.org>
[not found] ` <<6762abf5-71c1-aa54-1bac-d4c90c20870b@yandex.ru>
[not found] ` <<831rmavsuq.fsf@gnu.org>
2020-06-20 22:55 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6dc2c2ac-8e17-f044-dc78-8c109f936ad2@yandex.ru \
--to=dgutov@yandex.ru \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=philip@warpmail.net \
--cc=theo@thornhill.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).