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: Sat, 20 Jun 2020 15:32:22 +0300 Message-ID: <83y2ohvrxl.fsf@gnu.org> References: <87bllfqj82.fsf@warpmail.net> <626efe11-0f9c-081b-11dd-0d61cee8168d@yandex.ru> <83h7v7xf7w.fsf@gnu.org> <831rmayj55.fsf@gnu.org> <6dc2c2ac-8e17-f044-dc78-8c109f936ad2@yandex.ru> <83wo42w83e.fsf@gnu.org> <83a70yw1y8.fsf@gnu.org> <87mu4ym6f6.fsf@thornhill.no> <834kr6vymb.fsf@gnu.org> <90f4c9e8-bf8d-3b27-a8a9-ed44c5d23839@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="107292"; 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 Sat Jun 20 14:33:31 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 1jmcgb-000Rmg-J3 for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 14:33:29 +0200 Original-Received: from localhost ([::1]:37946 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmcga-00007O-LX for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 08:33:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36288) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmcfi-0007cu-KI for emacs-devel@gnu.org; Sat, 20 Jun 2020 08:32:34 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38601) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmcfh-00031x-UC; Sat, 20 Jun 2020 08:32:33 -0400 Original-Received: from [176.228.60.248] (port=4519 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jmcfg-0008UW-Mc; Sat, 20 Jun 2020 08:32:33 -0400 In-Reply-To: <90f4c9e8-bf8d-3b27-a8a9-ed44c5d23839@yandex.ru> (message from Dmitry Gutov on Sat, 20 Jun 2020 14:35:24 +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:252439 Archived-At: > Cc: philip@warpmail.net, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sat, 20 Jun 2020 14:35:24 +0300 > > On 20.06.2020 13:07, Eli Zaretskii wrote: > > In any case, my proposal was not about the API itself, it was more > > about the implementation of the API. For example, we could have an > > implementation of the generic project-files API that consulted some > > list instead of asking the VCS or the filesystem to provide the files. > > You can of course do this already, in 10 lines or so. I'm a user. I don't want to write code every time I want something simple from the project-related commands. I expect such simple use cases to be supported OOTB. > But imagine you did add such a backend where project-files returns an > arbitrary list of files. And you use it. > > How would project-switch-to-buffer consult it? Will it have to call > project-files now, as opposed to just using project-root as the basis > for comparison? And then compare buffer-file-name of all file-visiting > buffers against that list? That's one possibility, yes. > That would work for smaller projects, but in large ones project-files is > not instantaneous, so they will be penalized in performance by such an > approach. We have faster data structures than lists. We could use them. And in any case, we should identify the needs first, and then implement the features that support those needs. Rejecting some of the needs because they don't fit the current implementation is the wrong way for designing features such as this, which is supposed to be part of our IDE infrastructure. > And project-switch-to-buffer should work with all kinds of projects. Yes. And one such kind is an ad-hoc collection of files and buffers, where only the user knows which ones he/she is interested in and which ones he/she isn't. Every IDE I saw supports something like that, so we should do that as well, IMO. > That also wouldn't solve the problem of non-file-visiting buffers like > Grep from your example. You talked about project-files, so buffers that don't visit files are excluded, of course. But an indication that supports marking buffers as belonging to a project could support both file-visiting and non file-visiting buffers.