[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Subprojects in project.el (Was: Eglot, project.el, and python virtua

From: Dmitry Gutov
Subject: Re: Subprojects in project.el (Was: Eglot, project.el, and python virtual environments)
Date: Fri, 25 Nov 2022 23:57:51 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 25/11/22 21:45, Eli Zaretskii wrote:
Date: Fri, 25 Nov 2022 19:24:26 +0200
Cc: joaotavora@gmail.com, monnier@iro.umontreal.ca, danny@dfreeman.email,
  eric@ericabrahamsen.net, emacs-devel@gnu.org
From: Dmitry Gutov <dgutov@yandex.ru>

On 25/11/22 09:30, Eli Zaretskii wrote:
I'm probably missing something: how does a Lisp program construct an
instance of a project with a known backend?  For example, if the project is
of the 'transient' kind, how would such a Lisp program go about constructing
an instance without exposing/knowing about the internals of the project
object?  I see no generic make-project API that such a Lisp program could
call.  What did I miss?

The Lisp program that constructs instances of 'transient' is

I meant to ask about building customized project objects, not the standard
ones that are already created by project-current.  This started with a
function João wrote to that effect, and he wrote it, AFAIU, because the
standard kinds of project objects didn't satisfy his needs.

No, again, he just wanted to show a quick example. With pseudocode, almost like.

The program that creates instances of 'vc' type is called
'project-try-vc'. But we could similarly add a generic method belonging
to the same unit of code (called 'project-subprojects') which would
"belong" to the VC project backend and create a list of instances of its

Again, you are talking about project kinds already supported by project.el
as its built-ins.  I'm asking how to produce a project of a custom type.

To produce a project of custom type, you decide the data structure for that type, write implementations for all the required (and perhaps some optional) generic methods, then create that structure.

You asked, however, how to instantiate a project of a type belonging to "someone else". But didn't explain why.

In most cases we will say it's not a good idea, but when a practical goal is described we will decide to either say "go ahead, it's okay in this case", or, hopefully, suggest a different way to reach that goal (just like I did with the 'project-parent' definition example). Or rethink and throw away the whole design (hopefully not).

The reasons not to rely on internal structure, as a reminder:

- The internal structures are prone to change, and you don't want your code to break when that happens. - When implementing some feature that works with projects, you generally want it to work with all kinds of projects (which was the whole point of project.el -- to make this approach work). And that would mean talking to them through common methods, rather that examine the internals of this or that project type.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]