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: Sat, 20 Jun 2020 15:36:37 +0300 Message-ID: <83v9jlvrqi.fsf@gnu.org> References: <87bllfqj82.fsf@warpmail.net> <83o8pfxhzq.fsf@gnu.org> <83imfnxgt3.fsf@gnu.org> <83eeqbxevp.fsf@gnu.org> <87bllfnjy5.fsf@thornhill.no> <83d05vx9or.fsf@gnu.org> <877dw3ne2z.fsf@thornhill.no> <83a70zx7ag.fsf@gnu.org> <874kr6oqz1.fsf@thornhill.no> <834kr6yk27.fsf@gnu.org> <83y2oix431.fsf@gnu.org> <158b0bbb-01c1-0a3e-ceaa-69eb9c2b22f4@yandex.ru> <83pn9uw6cm.fsf@gnu.org> <0a2b7b06-f6ac-2e33-0901-d56e3f94f260@yandex.ru> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="125048"; mail-complaints-to="usenet@ciao.gmane.io" Cc: theothornhill@pm.me, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 20 14:37: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 1jmckW-000WQw-DW for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 14:37:32 +0200 Original-Received: from localhost ([::1]:39950 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmckV-0002QT-F7 for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 08:37:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37466) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmcjm-0001WH-So for emacs-devel@gnu.org; Sat, 20 Jun 2020 08:36:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38635) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmcjl-0003fa-Oi; Sat, 20 Jun 2020 08:36:45 -0400 Original-Received: from [176.228.60.248] (port=4782 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jmcjl-0000cy-41; Sat, 20 Jun 2020 08:36:45 -0400 In-Reply-To: <0a2b7b06-f6ac-2e33-0901-d56e3f94f260@yandex.ru> (message from Dmitry Gutov on Sat, 20 Jun 2020 14:41:22 +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:252440 Archived-At: > Cc: theothornhill@pm.me, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sat, 20 Jun 2020 14:41:22 +0300 > > On 20.06.2020 10:20, Eli Zaretskii wrote: > > >>> Not as part of working on the current project. Though I might decide > >>> to add some of them to the current project, as the need arises. > >> > >> I mean, do you visit them in the same Emacs session? > > > > I just answered that above. This is all in a single Emacs session. > > What I meant is, is there harm in modeling that kind of project as VC > project with just lots of exceptions (additional ignores). Or is that > just difficult. I don't understand the question. What is a "VC project", and how is it relevant to the use case I described with grepping another directory to see how others solved some problem? > >> OTOH, we already have a customization point that allows to exclude more > >> files than .gitignore does (the project-vc-ignores variable). > > > > I don't think exclusion alone is enough. We need also a way of > > _including_ files in a project. > > It's on my list. As long as we're talking about whitelisting files in > the same directory tree. That's part of the issue, but it isn't all of it. > But also see project-external-roots. That supports only entire directory trees, so is not selective enough, IMO. > >> *And* one can use the project API to introduce a project backend that > >> does not rely on VC repositories. > > > > I think we should have commands to do so in the core. It's too basic > > a capability for any IDE for us to leave it to add-ons. > > Commands? Project backends are applied automatically in the current model. Don't understand what you are saying here, either. Are you saying a backend cannot support some notion of starting a project, or of adding a file to a project?