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, 21 Jun 2020 18:08:04 +0300 Message-ID: <83a70wv4mj.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> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="128071"; 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 21 17:08:46 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 1jn1aP-000XD5-Bn for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Jun 2020 17:08:45 +0200 Original-Received: from localhost ([::1]:42232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jn1aO-0007kT-EO for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Jun 2020 11:08:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40310) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jn1Zs-0007Fv-Vk for emacs-devel@gnu.org; Sun, 21 Jun 2020 11:08:13 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53586) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jn1Zr-0004qr-C4; Sun, 21 Jun 2020 11:08:11 -0400 Original-Received: from [176.228.60.248] (port=2794 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jn1Zq-0003AS-MM; Sun, 21 Jun 2020 11:08:11 -0400 In-Reply-To: (message from Dmitry Gutov on Sun, 21 Jun 2020 02:11:18 +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:252493 Archived-At: > Cc: theo@thornhill.no, philip@warpmail.net, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sun, 21 Jun 2020 02:11:18 +0300 > > I don't want to dismiss the critique outright. Believe it or not, I really do want you, personally, to be happier and more productive as a result of things I do here. I spent several hours today just thinking about this discussion. But our workflows are different, and expectations are different as well, and it seems that your requests tend to conflict with some design choices I have originally made. > > > One of them was to make the VC project a hands-off backend, one that immediately "just works" (or tries to), with a few possibilities for customization through local variables. This must be supported, of course. And the backend which treats an entire directory with its subdirectories as a project must also be supported. I'm not arguing for dropping any of these two. I'm arguing for adding yet another possibility, whereby the files belonging to a project are selected by the user, whether by marking in a Dired-like directory display, or by explicitly naming each file to be added, or by drag-n-drop. Based on the discussion of non file-visiting buffers related to a project, I think there should also be a command that would allow the user to include/exclude such buffers from the project, because it doesn't make sense to me to decide up front that any *shell* or *grep* or whatever buffers are automatically considered to be part of the project based on something as ephemeral as their default-directory. > You seem to think (and this is only my guess, of course) that a project is a unit of work. And that whatever files, or activities, are pertinent to your current goal, are a part of that project. Hence, if you do a search anywhere, in any directory, but in pursuit of that goal, the search results are certainly a part of the current project. It is certainly a valid viewpoint, but one that I have never considered before. I think it needs to be considered because it's a valid use case and happens in practice. It would be useful to support it OOTB. Even if all the files belonging to a project are in the same directory, the MO where _all_ (or a vast majority) of the files in a directory belong to the project is a serious limitation, and we shouldn't impose it on our users. Granted, one can produce a large enough exclude/ignore list to leave only a handful of files, but if just 5% or 10% of files in a directory should be part of a project, excluding the other 90% or 95% is a nuisance and an unnatural thing to do. > So I'm not sure where to go from here. If the latter viewpoint has more supporters, perhaps an new, alternative backend is the way to go. This would be a test of the API, how well it adapts to different goals. 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. > 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. > > I'm curious about those "every IDE". I don't recall such a feature in ones I tried. Perhaps I just didn't use it, of course. Few examples below: Code::Blocks: https://www.cs.odu.edu/~zeil/FAQs/Public/newIDEProject/index.html#creating-a-project-from-existing-code Visual Studio: https://docs.microsoft.com/en-us/visualstudio/ide/creating-solutions-and-projects?view=vs-2019 Look under "Create a project from existing code files", "Add files to a solution", "Create empty solutions" QNX: https://www.qnx.com/developers/docs/6.4.1/ide_en/user_guide/tutorials.html Netbeans: https://netbeans.apache.org/kb/docs/cnd/quickstart.html#_adding_existing_files_to_your_project TI's Code Composer: http://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_project-management.html#adding-or-linking-source-files-to-project