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: Mon, 29 Jun 2020 17:32:24 +0300 Message-ID: <83pn9i0wp3.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> <363e38af-9a1a-860c-0cb2-a498e8340a36@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="25663"; 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 Mon Jun 29 16:33:33 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 1jpuqi-0006Ya-Sh for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Jun 2020 16:33:32 +0200 Original-Received: from localhost ([::1]:39850 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jpuqh-0005Nu-SQ for ged-emacs-devel@m.gmane-mx.org; Mon, 29 Jun 2020 10:33:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45882) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jpupy-0004DE-P1 for emacs-devel@gnu.org; Mon, 29 Jun 2020 10:32:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:60373) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jpupx-0008Iy-AY; Mon, 29 Jun 2020 10:32:45 -0400 Original-Received: from [176.228.60.248] (port=3538 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jpupn-0000ol-Nh; Mon, 29 Jun 2020 10:32:44 -0400 In-Reply-To: <363e38af-9a1a-860c-0cb2-a498e8340a36@yandex.ru> (message from Dmitry Gutov on Mon, 29 Jun 2020 01:14:36 +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:252562 Archived-At: > Cc: theo@thornhill.no, philip@warpmail.net, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Mon, 29 Jun 2020 01:14:36 +0300 > > As such, I'd rather let someone else implement the project backend with > the features you outlined. And if someone decides to take it up, I have > a number of thoughts on how it can be better integrated. Implementing this, and the priority assigned to doing so, is not the main issue that bothered me, and caused me to start this thread. This is a tangent; see below. > OTOH, along the lines of Juri's opinion, perhaps your requirements could > be satisfied by making use of whitelisting entries in VC project config. Whitelisting is a nuisance when you need to whitelist too many files; blacklisting is a nuisance when you need to blacklist too many files. Other than that, both are fine. But again, that's not the issue here. > > I'm not talking in terms of backends, I'm talking in terms of > > user-facing features. I think we should decide whether a feature such > > as the above should be part of what project.el supports, and then > > consider how to implement it. I don't see why the implementation > > should be very complicated, FWIW, so there's no need to bring the > > implementation into the picture, not yet. > > A naive implementation should be pretty easy. What is difficult is > fitting this starkly different kind of interaction and configuration in > the current design. If this use case doesn't fit the current design, IMO we should rethink the current design. We are just beginning to implement the user-level features of project.el, so we should make sure adding other reasonable use cases will be as easy as we can envision today. _That_ is the problem that bothers me the most: that we already have restrictions on which use cases can and cannot be supported, although we barely started. > So ultimately, if you really want this kind of interaction, it would be > better to have a separate backend. It could also have a different author > than myself, thereby validating the idea that it is, indeed, something > that users want. We are constantly losing focus in this discussion, at least from my POV. The main reason I started this is that I think using default-directory for the decision which files/buffers belong to a project is not the best idea. Everything else I said, every example I brought up, was to show why we should rethink that design decision, and do so soon, not in some uncertain future. This is the only issue that really bothers me. I didn't ask you to implement the "project from existing files" feature, let alone change your priorities, I didn't request any new commands or features, I just wanted to show how this single design decision limits our future options. This issue, which is the only one important for me in this discussion, gets lost time and again, because you take each my example and each my argument, and start arguing about each one of them separately, thus drowning the main issue in an ocean of related, but secondary aspects of the problem. Please, try re-reading or reconsidering all I said in that light, and let's please return to talk about that one issue. Assuming, that is, that you are open to discussing that issue, and could be convinced to change your mind; otherwise, let's agree to disagree and finish this. TIA