From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: master 1e3b0f2: Improve doc strings of project.el Date: Sun, 28 Jun 2020 03:56:29 +0300 Message-ID: <5542db0c-cc0d-2743-87ae-7728a0cc94bb@yandex.ru> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="95387"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 Cc: philip@warpmail.net, theo@thornhill.no, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 28 02:57:16 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 1jpLdE-000Oj5-1t for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Jun 2020 02:57:16 +0200 Original-Received: from localhost ([::1]:43082 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jpLdD-0000A0-38 for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Jun 2020 20:57:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52528) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jpLcb-0008Al-Em for emacs-devel@gnu.org; Sat, 27 Jun 2020 20:56:37 -0400 Original-Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]:33560) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jpLcZ-0004cX-8z; Sat, 27 Jun 2020 20:56:37 -0400 Original-Received: by mail-ej1-x62e.google.com with SMTP id n24so12835985ejd.0; Sat, 27 Jun 2020 17:56:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xyfTrrPCCP9gEYeInBx9MkUSmxiq19oDTxeVYqOXg1k=; b=q0rQ+Uhpr97jsk7LOyuO/V+7wmZGRXMfEf9LI9ywvvCg9S2r6JEHWM2zu6nQQJC8FI WNJWaud4A0HpjkXa4sEw/lKXYOi0W547xHS2cF4pnRWBZBAPznlNfBfu2yIS+E6NeNRv V2d+sPZSH4+bqB/3M/uXJgvMLT4hxwGDEzzLfLFcER02qS3a+1XFcgouWNUNBgXnYBYj mYE+ON23Gag4FLr1KMGIvnCalGoklMXoWw4hI+Npm3Q5qgXtq37pZO9RGCwCqErRiLDg +5Xv1G6CEA5o3haS5vZv6xzqS853wpebtggWThjbmyTIQrZSML3QpP1v7IZrwtMh4/9+ yckQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xyfTrrPCCP9gEYeInBx9MkUSmxiq19oDTxeVYqOXg1k=; b=WTdteaakd6JwfOJcLtU/MFkVv6o9+eA3cIeka6aFMn/ZhLbX95Ee9ZSXMYGA4Y7hTv TymTeyMtxxyK3yY+iZuZUucpCR3XJp2rw1ANKyDKF913BQ93iqLavP+WYvWN+W6ppAJj ia5OnSL+uWC4KHwKKzgLkUSeGlxX2qRI5zLHfiXqYTyNtkXFEPzQUKaNgdnjY+DUzXij lev2XRoP+hSWO7O10AWKhTtUF7Pned4o9T6wC5t1j5peWg57TDsiPkuEc0Hl7KE5jTtj KeKP0etMf+RbQEriRNGdLvBvBIi5d22naKXLoMIREZnBy/EffSvhxFX/9yJbUhBhwEZS h0/A== X-Gm-Message-State: AOAM533+xpTJriNzr9GzgXJ4lLCSXBu0eoFw3gICRE2zDw1NLpMk9sej s8EY6DeH6WyudO44sZqIZRx1Lwt/ X-Google-Smtp-Source: ABdhPJy3rvw/8pgn0cvE7ZouWZ48cU+9VeXIuNvZ3u5uBn7izrkqdOste+hp1wbi9INiEF+3Ofz2jw== X-Received: by 2002:a17:906:398f:: with SMTP id h15mr743049eje.391.1593305792613; Sat, 27 Jun 2020 17:56:32 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id w8sm24528619eds.41.2020.06.27.17.56.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 27 Jun 2020 17:56:31 -0700 (PDT) In-Reply-To: <83a70wv4mj.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::62e; envelope-from=raaahh@gmail.com; helo=mail-ej1-x62e.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: 0 X-Spam_score: 0.0 X-Spam_bar: / X-Spam_report: (0.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=1, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:252550 Archived-At: Hi Eli, Thanks for these examples. Commends below. On 21.06.2020 18:08, Eli Zaretskii wrote: >> 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 Going by "Navigate to the directory where you already have your code.", it seems to expect that all project code resides in the directory the user specifies. Although, for some reason or other, it decides to default to not listing existing source code in there in the "sources" section. Perhaps that has to do with build configuration. Note A: Being able to tell "source files" from the rest of the project files is a concern that we haven't looked into yet (nor into its applications). In the default backend, though, I would like to have it work automatically as well (probably by having a configurable list of globs/file extensions/etc). Note B: If you only meant this as an illustration of including certain files in the directory, this setup should be supportable when we add support for whitelisting entries (as opposed to just blacklisting ones, through in project-ignores). That would still require all files to be contained inside the directory that is designated as "project root directory". > 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" "Create a project from existing code files" actually makes VS pick up all the source files in the chosen directory, from what I can tell. In that, it's closer to our project-vc backend than to Code::Blocks. "Add files to a solution" talks about having a file that "applies to multiple projects". Which talks about a case of spreading the current work contents across multiple root directories. Which is what its "solutions" are. As far as how to support a notion similar to solutions best, I'm not sure. Perhaps it indeed would be a separate thing (package/feature/etc), with a file-based configuration, that points at projects included in it. That way, project-vc backend (and others) could be reused for included projects. And we could have solution-level commands (e.g. solution-find-file, which scans across all included projects). I don't understand the level of demand for this among our users, and as such, the necessary features. We're not at the level of complexity that Visual Studio has (WRT build configurations support, etc), and most other text editors I know don't have this feature, so perhaps it's a bit premature. The good news here, however, is that implementing solutions as a separate feature on top of project.el should be relatively simple. And people are welcome to experiment. > QNX: > https://www.qnx.com/developers/docs/6.4.1/ide_en/user_guide/tutorials.html It seems to describe a situation similar to MS VS, except "solutions" are called "workspaces" here. Otherwise, you don't select individual files inside a project to be added. > Netbeans: > https://netbeans.apache.org/kb/docs/cnd/quickstart.html#_adding_existing_files_to_your_project "Creating a Project With Existing Sources" seems to import all source files within a project directory automatically. I wonder what "Adding Existing Files to Your Project" does. Perhaps it copies files from elsewhere into the project directory, if it's not there yet. > 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 The "physically copied" case is obvious. Regarding "When you link a file/folder to a project ...", does it create a symlink, maybe? That wouldn't require a configuration change. 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. 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. (To be continued, to address the rest of the email.)