From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master 1e3b0f2: Improve doc strings of project.el Date: Fri, 19 Jun 2020 22:01:42 +0300 Message-ID: <831rmayj55.fsf@gnu.org> References: <87bllfqj82.fsf@warpmail.net> <83o8pfxhzq.fsf@gnu.org> <83imfnxgt3.fsf@gnu.org> <626efe11-0f9c-081b-11dd-0d61cee8168d@yandex.ru> <83h7v7xf7w.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="18264"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philip@warpmail.net, theo@thornhill.no, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 19 21:03:04 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 1jmMI4-0004du-2e for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 21:03:04 +0200 Original-Received: from localhost ([::1]:41514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmMI3-0001B9-1u for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 15:03:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58012) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmMGy-0008Ni-Jt for emacs-devel@gnu.org; Fri, 19 Jun 2020 15:01:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53896) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmMGx-00072T-0x; Fri, 19 Jun 2020 15:01:55 -0400 Original-Received: from [176.228.60.248] (port=3856 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jmMGw-0008U7-6m; Fri, 19 Jun 2020 15:01:54 -0400 In-Reply-To: (message from Dmitry Gutov on Fri, 19 Jun 2020 21:33:34 +0300) 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:252405 Archived-At: > Cc: theo@thornhill.no, philip@warpmail.net, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Fri, 19 Jun 2020 21:33:34 +0300 > > >> If the current project contains a few other projects inside of its > >> subdirectories, project-switch-to-buffer probably should offer any of > >> "their" buffers for switching. > > > > "Should" or "should not"? If the former, then the text I proposed is > > fine as it is. > > Sorry, should not. > > 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. > >> As soon as you start relying on completion hints, you don't need to > >> remember the names in advance. And it's also a good overview of the > >> current open buffers in the current project. > > > > If this is just for completion's sake, then I could understand, but > > still it sounds very strange to include stuff like *XREF*, Eshell, > > Occur, *Compilation*, *Grep*, etc. Those are basically singletons, at > > least by default, > > 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. 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). > 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). > > 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.