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/msg01511.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: Dmitry Gutov Subject: Re: Subprojects in project.el (Was: Eglot, project.el, and python virtual environments) Date: Thu, 24 Nov 2022 05:01:30 +0200 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 
On 23/11/22 15:57, João Távora wrote:

It would be much more helpful in a dedicated bug report where we could
discuss the details, collect the votes and see what kind of design
will ultimately satisfy the requirements. Instead of drowning it all
in this thread, which is only moderately related.

I think we're doing fine here but I've changed the subject line to
"unbury" it from the thread.

You're fussy about proper bug reporting in your projects, but somehow do not extend that courtesy to others. 




 

  
And even if we do, we might not need the additional notion of
sub-projects. E.g. 'search in the parent project (if any)' might work
as "take the root, go up a directory, search for a project there; if
it exists, use it". Though Stephen L. might want a generic for that,
since his projects do not correlate with directory tree.


 

 
And in my case, sub-projects don't necessarily exist exactly one-level
down super-project's root.  Sometimes they do, but now always.





I don't think that's important whether it's one-level down exactly:

(defun project-parent (project)
  (project-current nil (file-name-as-directory
                        (file-name-directory
                         (directory-file-name (project-root project))))))





 

  
If we wanted to define projects and subprojects through the same hook,
the step "get all subprojects of the current project" might not be
feasible to implement. Because of performance-related considerations.


 

 
Those remain to be seen, I can't guess what things you're imagining.





I'm imagining that traversing a directory tree with an arbitrary predicate is going to be slow. If the predicate is limited somehow (e.g. to a list of "markers" as base file name, or at least wildcards), 'git ls-files' can probably handle this, with certain but bounded cost. 

I wrote about this in another email here yesterday.











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