What's a project? workspace?

[dschaefer]

After years of struggling with the Eclipse resource management model, I'd love to keep that fight out of Two. Text editors like VS.Code somewhat have done away with formal projects and things seem to work OK. Though things may be at the workspace level now.

My original thinking and what I have in the FileExplorer is the idea of mount points. You mount one or more directories from the file system as root nodes in the file tree. And that mainly done to reduce noise and leave off directories you don't plan on working in.

Question is, how do we do some of the things we got used to when we had projects in Eclipse. Things like inter project dependencies, or per project build and indexing settings.

I think those things could be done on the folder level. Extensions could analyze the files that exist in the tree under a folder and apply semantics at that level. I'd like to add an editor for folders that shows details about the files but that is also extendible to allow management of folder level settings. Github kinda does this showing the README files for a folder.

Anyway, not sure how this would really work. Need some real world experience with it. Any advice from anyone would be appreciated.

[ttoine]

Atom is based on Electron, too. Did you have a look at how they manage a project?

[ccampo]

Too me project-based thinking is important for Java projects (OSGI or not) where you create project-based artifacts. For Javascript Single Page apps you dont have projects (a lot of the time) because you just create one artifact the Web application. While I think that mount points and all this is a great idea I believe we need projects for Java or other JVM based languages at least. How about putting the functionality about projects into a plugin if you like to leave it out of the core of Eclipse Two ? That way you add the plugin and now you can manage projects without polluting the E2 (Eclipse Two) code base.

[dschaefer]

@ccampo Yes, I think that's the best. Will have to think how we'd handle different languages and see if there is anything in common. For example, many users are used to a "Build" button on their IDEs. Would need to understand if it has a place here and if so, what information would it need to do a build (beyond the obvious running a build command in a given directory).

@ttoine Atom is an editor. So I'm not sure it needs the concept of project. And Electron is really just a UI framework (Chromium) and JavaScript runtime (node.js). It wouldn't have an opinion in this area.

[ttoine]

@dschaefer Not sure how it works, but Atom is actually able to manage projects. Maybe just with the root folder, or something like that. You can perhaps take some good ideas here too. Please have a look at the screenshot.

And no, it's not "just an editor". You can search/replace ... strings in all the files of a projects, and with all the available plugin, you can have a quite complete development environment. Many of my friends working on web applications switched to Atom.

[dschaefer]

I see they have a thing called "Project Folder" but I can't tell if there are any semantics to it. Am I missing something?

[dschaefer]

And, yes, Atom is an editor. I have a much grander vision for what an IDE is than what Atom provides.

[ttoine]

I agree, Atom is an editor: I never told that it was more than that. (like VS Code, btw)

However, it's already appreciated and adopted by a lot of developers I know: with a few plugins, you can set up a very interesting development environment. Particularly, when the debugger is in the browser or on the cloud, it is really efficient. Ok, it doesn't have LSP. But as this is one of the most active, and most complete Electron based app, there are certainly some interesting things to get inspiration from. (projects or root folders, plugins management, ...)

And it is also available with an MIT license.

That said, I am very curious to see what you can achieve with your project.

[dschaefer]

Interesting. I'll likely run into this with Phase 1. I need to feed the options in the ts.config file to Monaco for TypeScript. That means I pretty much need to know what a Build is, i.e. what the tsc compile arguments are. IDEs work much better if we know what the build process is so we can interpret the source dependencies correctly.

[ghost]

For what it's worth, Atom has alpha LSP support now (atom-languageclient) and basic IDE integration based on LSP. Atom simply treats the folder you open (the workspace) as one project, and assumes everything you need is inside it. Beyond that, it doesn't add any project file or project settings or anything, but lets the language-specific plugins handle such things if you need them. I quite like that approach. E.g. the language plugin for java simply can check for ant files or other files that specify the build process.

Visual Studio Code on the other hand seems to have a basic VS Code settings file per project, but as far as I'm aware you simply don't need to use it if you don't want to change any of the default-assumed settings.

[dschaefer]

I still haven't found out how VS.Code handles this. Seems very incomplete. Looks like Atom has hit the right note.

The biggest problem for us in the C/C++ world is the project system in Eclipse is very intrusive. Having things more freeform and that just does the right thing is the best approach. Most projects developers set up manually start at a root directory which has all the build scripts and such they need. We need to fit into those paradigms and stop forcing developers into ours.

[ghost]

Yea I really like that Atom doesn't require any settings or project file at all. I think the best approach is to recognize common command line build systems (ant, cmake, ..) and simply support those as project build info instead of setting up an actual, editor-specific build settings file. I can't tell how well that translates to Java specifically though, I don't use it that much.

Also, the obvious downside is that for unknown build systems the editor can become a bit useless. But for that case one could still add an optional custom build plugin with a dedicated settings file, right? I don't know if Atom actually offers that, but that seems like the obvious solution for this corner case with an Atom-like approach.

And many modern languages like Python, Rust or Go seem to bring their own default build tools anyway which everyone uses, so the C/C++ problem of a thousand different build tools that need to be support doesn't really exist there.