Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] VS Code


On 14 September 2016 at 07:26, Mickael Istria <mistria@xxxxxxxxxx> wrote:
On 09/13/2016 10:46 PM, Pascal Rapicault wrote:
Project-less workspace is the way to go for all projects. At at time where Java did not had build tools to structure things, Eclipse concept of project made sense. Now that every language and ecosystem comes with a build tool, the concept of project a-la Eclipse is becoming an annoyance.
 Several other languages still don't have decent build tools, and if you think about people beginning with Java, they don't have build tools.
This concept of "projects" is IMO a natural and good one, the issue in Eclipse IDE isn't its existence but its interaction with overlapping concepts, such as build tools or edition capabilities according to enabled natures. All IDEs have some project or module concept, and it's pretty convenient to browse an enriched scoped tree when manipulating them.
The issue with Eclipse IDE is that many code assistance features only work if 1. file is part of an existing Eclipse project (with .project), 2. this project is loaded in the workspace and 3. the project has the right nature; whereas several of them could work without these constraint.
So yes, every feature should do its best to work directly on a File (not requiring an IFile). Should it be a recommendation for the UI Working Group?


I agree with Pascal here. Most new languages come with a build system and dependency management system, such that the concept of Eclipse IProject's becomes less and less important. Even more true for IDEs that use external tools for building and language analysis/navigation. It is certainly the case for Goclipse, RustDT and DDT. They are made to work with File/Path, and the Eclipse resource model is almost entirely unimportant.
The only use for IProject's at the moment is to store project-specific configurations, but even that I have plans (if I ever have the time) to move to a preference configuration system that can scope on any filesystem directory location, regardless of it being an IProject or not. (and also make Eclipse-independent)

Of the big languages, only Java is somewhat behind in this aspect because it does not have a standard module system... there's Maven, OSGi, and then upcoming Java 9/10 module system too... So there is fragmentation.

As for LSP (which is not much of an UX issue BTW), I do think it will most likely become the future of IDE and language integration. It is just needing some time for language implementers to pick it up. It was announced very recently after all.
I also don't see LSP protocol limitations as a big issue. You can always introduce language-specific extensions to the protocol, which IDEs can then optionally support or not (just do it a way that doesn't break the standard protocol). Eventually, as this space is explored more, I imagine good non-standard extensions would eventually be merged into the standard protocol.

--

Back to the top