From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) Date: Fri, 02 Dec 2022 16:16:55 +0200 Message-ID: <83cz91gaaw.fsf@gnu.org> References: <87zgcq68zp.fsf@ericabrahamsen.net> <87o7t2vj19.fsf@dfreeman.email> <877czqtyfy.fsf@dfreeman.email> <87zgcml7g7.fsf@gmail.com> <2ba04533-097a-a1da-ff3f-2c9506fd488e@yandex.ru> <875yf9bbzb.fsf@gmail.com> <87wn7oa0aw.fsf@gmail.com> <7a5b76fd-fb15-8c1e-ea29-bf11f7e0d2ae@yandex.ru> <87bkoya815.fsf@gmail.com> <0024a67d-b8e5-b35c-1b22-82541a170eb3@yandex.ru> <871qptai4d.fsf_-_@gmail.com> <83o7swyipe.fsf@gnu.org> <83sfi7v6dj.fsf@gnu.org> <45549e6b-942f-ee99-9123-8176545a159e@yandex.ru> <83zgceu8ch.fsf@gnu.org> <7c34024e-c2b6-033f-ff37-a0fdfc9f0cdb@yandex.ru> <83v8n2tbur.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="601"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, danny@dfreeman.email, eric@ericabrahamsen.net, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 02 15:18:09 2022 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 1p16re-000AMm-M9 for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Dec 2022 15:18:06 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p16qy-0002c1-CD; Fri, 02 Dec 2022 09:17:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p16qw-0002bl-1y for emacs-devel@gnu.org; Fri, 02 Dec 2022 09:17:22 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p16qu-0006cv-OJ; Fri, 02 Dec 2022 09:17:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=xqeFt8nikzIR/IeEredDqFeBvxLSVo28WO/YjDrYU8U=; b=WeDDCJdwTNPJ qeMVwCYfXg1Kfw7ZZS8X24pxgRb0UlTBDWtMPdXtox9yrhJTChPHysC7GFtMvn7u2ffut0y/phLYg HeSojynbydhEuxps83V5qYbZv7Glk+IZxqk3DN1QPo8wBGBY5H+n32pfgeda7dCm66WbYsRSwLAth LLE/hxw4XcVHmzlTY7VArbISZQOiVxvBfkAkwy93mQ8qCxAfo8nDhdwaQNLUmb1vRAUQmxBFx/2Ii 1zfW5cJFyUGpJtmrINf5MjEtEp8c7ZqJTvK51EQqldth3pk2xGt5mwkjBCtrPQL29I+NxkKRrfmiH VUXLFGvpMvliUDHQ622Dfg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p16qu-0006ZO-6T; Fri, 02 Dec 2022 09:17:20 -0500 In-Reply-To: (message from Dmitry Gutov on Fri, 2 Dec 2022 03:32:42 +0200) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:300834 Archived-At: > Date: Fri, 2 Dec 2022 03:32:42 +0200 > Cc: monnier@iro.umontreal.ca, danny@dfreeman.email, eric@ericabrahamsen.net, > emacs-devel@gnu.org > From: Dmitry Gutov > > Still, if you do want to inherit from 'VC-aware', we can make a public > constructor for it. Probably after Emacs 29 is released, and we can see > that the structure is settled (it's looking this way now). > > As for 'transient', well, the constructor can be added as well. The > structure is stable and least likely to change; unless we just make an > executive decision to turn them all into structs or whatever. I just > didn't want to encourage people using it -- even Joao's usage is odd > because he not only calls the 'project-root' function, but also > 'project-files', and it's just luck that its behavior suits his current > goals. I'm just surprised that a simple request to be able to create a project type that is not one of the 2 built-in types is not answered by a simple "use this and that APIs". project.el strives very hard to be generic, but what is the use in doing that if extending it by 3rd-party code is so complicated, and on top of that is not already available? So yes, I think we do have public constructors and whatever else could be reasonably needed if one wants to subclass either of the two built-in project types. For this purpose, I don't think it matters how rich the built-in type is -- that is something for the sub-classing application to worry about. We just need to give them enough rope, and leave the rest up to them, IMO.