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: Sun, 28 Jun 2020 17:28:49 +0300 Message-ID: <83ftaf2rj2.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> <831rmayj55.fsf@gnu.org> <6dc2c2ac-8e17-f044-dc78-8c109f936ad2@yandex.ru> <83wo42w83e.fsf@gnu.org> <6762abf5-71c1-aa54-1bac-d4c90c20870b@yandex.ru> <831rmavsuq.fsf@gnu.org> <83a70wv4mj.fsf@gnu.org> <5542db0c-cc0d-2743-87ae-7728a0cc94bb@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="83703"; 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 Sun Jun 28 16:33:28 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 1jpYN6-000Lez-3Q for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jun 2020 16:33:28 +0200 Original-Received: from localhost ([::1]:49196 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jpYN5-0003di-17 for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jun 2020 10:33:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39328) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jpYIp-0005IJ-Nn for emacs-devel@gnu.org; Sun, 28 Jun 2020 10:29:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43294) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jpYIo-0005TO-QU; Sun, 28 Jun 2020 10:29:02 -0400 Original-Received: from [176.228.60.248] (port=1890 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jpYIm-0007uo-Tj; Sun, 28 Jun 2020 10:29:01 -0400 In-Reply-To: <5542db0c-cc0d-2743-87ae-7728a0cc94bb@yandex.ru> (message from Dmitry Gutov on Sun, 28 Jun 2020 03:56:29 +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:252552 Archived-At: > Cc: theo@thornhill.no, philip@warpmail.net, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sun, 28 Jun 2020 03:56:29 +0300 > > To sum up, what I saw here is mostly what I'm already used to anyway: a > project is basically a directory with some files in it (the set is > generally based on the principle of exclusion, but some subviews can be > based on inclusion/whitelist as well), and not an arbitrary set of files > from random places on disk. > > Not to discourage alternative workflows, but this is the concept we > should work on supporting well first. What do you mean "first"? why cannot we support both the workflow you are familiar with and the other kind? It isn't like adding such support is exceptionally hard, it just needs to find an alternative to making decisions based on the default-directory alone. And how is your summary above not a "discouragement"? > I should also note that these other editors have no concept of > "buffers", and thus no way to configure their inclusion of exclusion. > Thus, any entity that might correspond to our non-file-visiting buffers > (such as a search window, or a compilation output window) is likely > implicitly considered to just be part of the current project or > solution. Please feel free to correct me here. The problem I raised is twofold: . non file-visiting buffers could have a default-directory outside of the project's root, and still be relevant to the project (I provided a couple of examples) . file-visiting buffers can live in the same directory, but belong to different projects Thus, using default-directory as the sole or the main indicator of belonging to a project limits us in the use cases we can easily support. The examples I provided were in response to your request to show IDE capabilities to add existing files to an empty project, thereby creating a project from existing files and not from a directory. But I have said all this several times already, and at this point it sounds like whatever I say, whichever examples I show, you will still discard them and maintain that using default-directory is a good method, so it doesn't look like this discussion is going anywhere...