A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01563.html below:

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] From: Eli Zaretskii Subject: Re: Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) Date: Fri, 25 Nov 2022 09:30:00 +0200 
> Date: Fri, 25 Nov 2022 00:11:29 +0200
> Cc: monnier@iro.umontreal.ca, danny@dfreeman.email, eric@ericabrahamsen.net,
>  emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> > Is this okay for code outside project.el to know the internal structure of a
> > project object in general, and in particular cons "by hand" a 'transient'
> > project object?  I thought this was a closely-guarded implementation detail
> > that even doc strings are not allowed to divulge?
> 
> Joao's code here is not production-ready, but it wasn't intended as such 
> either, I guess.
> 
> Any 'sub-projects' function would likely be generic with implementations 
> belonging to a particular backend. And a backend knows how to construct 
> its instances.

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?

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4