From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: master 1e3b0f2: Improve doc strings of project.el Date: Fri, 19 Jun 2020 22:28:39 +0300 Message-ID: <6dc2c2ac-8e17-f044-dc78-8c109f936ad2@yandex.ru> References: <87bllfqj82.fsf@warpmail.net> <83o8pfxhzq.fsf@gnu.org> <83imfnxgt3.fsf@gnu.org> <626efe11-0f9c-081b-11dd-0d61cee8168d@yandex.ru> <83h7v7xf7w.fsf@gnu.org> <831rmayj55.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="441"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Cc: philip@warpmail.net, theo@thornhill.no, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 19 21:29:17 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jmMhR-000Y1G-Cj for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 21:29:17 +0200 Original-Received: from localhost ([::1]:40858 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmMhQ-0005qZ-D5 for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 15:29:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37188) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmMgw-0005Ja-Ck for emacs-devel@gnu.org; Fri, 19 Jun 2020 15:28:46 -0400 Original-Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:42948) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jmMgu-0003I0-Do; Fri, 19 Jun 2020 15:28:46 -0400 Original-Received: by mail-wr1-x430.google.com with SMTP id o11so3057260wrv.9; Fri, 19 Jun 2020 12:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=G44tBswrcFinQoVKHxBsizwciVVU+Yk00Cdx3Qsrw2A=; b=Wg3XpYa+CqIjmxEK31q7MCZuvQb+YGjGuGbqxBpa5nzw1ZaktutibI9xGD8RES2cXX BpHSo5+0PJKlsDzKWwwJHzXTKO0ZXTkUbJdrFMBLTEuvSZ1lhhLtkVnKnwfZ9sBQX6WX agwYB8OVAd5ViDWvPWRZJXj+TkJnRgcPADvP4ttVyEe6QInbo15TPMKDE/8hKUb/wghH yvu5z+1Of4bw3cY1+chjPRqxuG9Ichab2yweoDW59liYHErMJpixlwWdYCM+Sy5tC33e 4NWG5qvlWxliLHXh+BSBNjvyhVeGTJoX5MEjTD3ujgdq+sx+VdETnj594mII6imnJbNI n5fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=G44tBswrcFinQoVKHxBsizwciVVU+Yk00Cdx3Qsrw2A=; b=gxegGpvzQltAAHReWubhY/Av1J2PQPFxbV+m59a7g1bFcQfIfrzYC73YBHDGe0/kpq h2/hQhjIk6p1nfCfsvFHzNV+URVbaT+gXlze5RLYRF+lzZcDCMYIA9CEcWB+ze1pS4iY WWrNtk+p8AkiA/ZAtODzyWdHcQpcPy1lJyyxDZrUJN//IVMaAnmAJ8SI1iNXnTOW5XF9 0QiFY73p2cukt1Mb147F5yNxNRTL6E4/rJ/P7I1K0izGqff0bSD56xJz74iKT63P7ibl 8ERsRHC4ihmHY5Q/stQfeNXBt/AYNLqvfaZpCozeGgCUsoxcaRJhtwTE6U8t0W08XdIf FF3g== X-Gm-Message-State: AOAM530j6ctYLLxQiG88zyoqge3HeeePXLJ/5IgmtDISt7QBpItOKZkY 0o3k1xQDWl3u5xyWey1bHdv7grxt X-Google-Smtp-Source: ABdhPJzjaeZNUrkPXyAQsPr+6ugoRlA7zoVikWx4nuca2ZSsOBe9VVF6mC8bzz5W/e9wCEBV6d0XQg== X-Received: by 2002:a5d:6986:: with SMTP id g6mr5803353wru.27.1592594922046; Fri, 19 Jun 2020 12:28:42 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id j6sm7150799wmb.3.2020.06.19.12.28.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Jun 2020 12:28:41 -0700 (PDT) In-Reply-To: <831rmayj55.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::430; envelope-from=raaahh@gmail.com; helo=mail-wr1-x430.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: 0 X-Spam_score: 0.0 X-Spam_bar: / X-Spam_report: (0.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=1, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:252410 Archived-At: 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.