From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Theodor Thornhill Newsgroups: gmane.emacs.devel Subject: Re: master 1e3b0f2: Improve doc strings of project.el Date: Sat, 20 Jun 2020 10:19:45 +0000 Message-ID: <87sgeqjayt.fsf@thornhill.no> References: <87bllfqj82.fsf@warpmail.net> <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> Reply-To: Theodor Thornhill Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="96522"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 20 12:22:29 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 1jmado-000P2E-6d for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 12:22:28 +0200 Original-Received: from localhost ([::1]:43844 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmadn-00019B-1w for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 06:22:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40630) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmabL-00088o-Uw for emacs-devel@gnu.org; Sat, 20 Jun 2020 06:19:55 -0400 Original-Received: from mail2.protonmail.ch ([185.70.40.22]:16235) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmabJ-0007cW-DJ for emacs-devel@gnu.org; Sat, 20 Jun 2020 06:19:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=protonmail; t=1592648391; bh=lKweOZUmEdPJus4Ab+p9WbZrHCyPu6NzoC/Ks3jJF7I=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=DyYxpnfNZuyU76lmzOEgTQgQsJDCcPiodILOlpQB1BU4U89PiMWxDbKHe56d0GySM mPNZHQknx9BNXZrH+xNzZvybjO8gV8CLbSwMyfFaCxj1oN1AGpvubPj9hWxcCAlPre lOEDwFJNXNRsVldAXgWofqCwVZ2vG8Jq1/oeTfT5N5TqOyw41FqHE9swAZd4/ULf5L tZtjmHTG39W6t9+IBUotL7o2JBnQSLqSXMwr+JtReYtAtwVmwqcevlDyfOdCOYGj2D 5KCvODEPROx9R57KMTc2Z14/MIJTEpDgTezw70qj43PwI4cor5v7q1GSSVWFJu8QOA Xz/9U066G4oHw== In-Reply-To: <834kr6vymb.fsf@gnu.org> Received-SPF: pass client-ip=185.70.40.22; envelope-from=theo@thornhill.no; helo=mail2.protonmail.ch X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/20 06:19:51 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -37 X-Spam_score: -3.8 X-Spam_bar: --- X-Spam_report: (-3.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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:252428 Archived-At: > Which API did you have in mind? > > 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. > Yeah, this is kind of what I was thinking with the 'project-additional-buffers' idea. This could be implementation agnostic as well, and be just a flat list connected to some root, persisted in the project list. As such, this will always be consulted when invoking "project-find-files", "project-switch-to-buffer" etc. Then we are free to implement and choose the "main" implementation of the API, most likely at first the VC version, since it is the fastest one. Later, other notions of projects could be added. However, I don't want to step too far into Dmitrys domain without him chiming in.