emacs-devel
[Top][All Lists]
Advanced

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

Re: IDE


From: Dmitry Gutov
Subject: Re: IDE
Date: Wed, 28 Oct 2015 04:30:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0

On 10/21/2015 05:52 PM, Lluís wrote:

I don't understand C. Is module1 still inside project? Is it still a dependency?
Do we treat it differently WRT to questions I've asked for the option A?

Ok, so what if we let project-types define project nesting?

Every new thing, like projects being allowed to have children (or modules; are modules different from projects?), or paths being possibly non-recursive, raises complexity of the API, and makes it less straightforward to use it.

That's why I asking questions: which commands people would want to see implemented, that would consume information about project structure, and how they would expect the said commands to behave WRT to nesting, submodules, etc.

For example, if when we're working on a submodule we don't *really* need to know that we're inside a bigger project (or at least don't need to impart that information to most project-related commands), we can avoid the notion of nesting in the API, and just ask any project implementation to return the "module" we're currently in as the current project.

And a lot of languages don't have the same kind of modules that Maven-based Java projects use. Would the notion 'children' be only useful for Java projects?

In most cases, it probably makes more sense to construct this nesting
programmatically by adding some logic during project auto-detection (e.g., read
some configuration file that is part of the project).

Yes, of course. A project implementation like that would probably read pom.xml (or equivalent), and construct the nesting based on that.



reply via email to

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