Provide .editorconfig support

[angelozerr]

Today .editorconfig is supported directly in vscode, IJ, etc

It should be really nice that Eclipse IDE provides this support too. It exists a discussion at https://bugs.eclipse.org/bugs/show_bug.cgi?id=457046

And I implemented a long time ago https://github.com/angelozerr/ec4e which works with genereic editor but cannot apply all settings.

[laeubi]

@angelozerr do you think you can prepare a PR for this to contribute the code to eclipse? I'll then open a CQ for this,

[mickaelistria]

The edition part seems to require TM4E. Do we want Platform to start depending on TM4E ? I personally wouldn't mind, but I think it should be discussed a bit more broadly.
If we don't want it, then things like langauge configuration and highlighting would have to be removed for the moment.

[jukzi]

some questions:
a) What happens when the .editorconfig contradicts the workspace settings?
b) What happens when the .editorconfig in the project folder contradicts the project settings?
c) When the projects setting are edited via UI will the .editorconfig reflect the change?
d) does "searching" for the .editorconfig use file system or eclipse workspace api?

[angelozerr]

At first I would like to say that ec4e is based on https://github.com/ec4j/ec4j an editorconfig parser that I have implemented which can provide the required information that we need for IDE (AST offsets of section, fault tolerant parser,etc) compared to https://github.com/editorconfig/editorconfig-core-java which don't give the capability to give some offsets.

The official site https://editorconfig.org/ references today the ec4j.

The ec4e should work well with Generic Editor but not correctly with old editor. Here a demo where you can see wizard in action, codemining to show number of files which matche the section, syntax validation of .editorconfig and the most important apply of setting for matched files:

The edition part seems to require TM4E. Do we want Platform to start depending on TM4E ? I personally wouldn't mind, but I think it should be discussed a bit more broadly.

Indeed, perhaps TM4E should take care of that?

a) What happens when the .editorconfig contradicts the workspace settings?

It is the .editorconfig which should have the priority. But any improvement are possible.

b) What happens when the .editorconfig in the project folder contradicts the project settings?

Again, it is the .editorconfig which should have the priority. But any improvement are possible.

c) When the projects setting are edited via UI will the .editorconfig reflect the change?

No.

d) does "searching" for the .editorconfig use file system or eclipse workspace api?

ec4j provide some abstract resource class to retrieve .editorconfig. ec4e implement them with Eclipse API IResource https://github.com/angelozerr/ec4e/tree/master/org.eclipse.ec4e/src/main/java/org/eclipse/ec4e/internal/resource

[merks]

I'm not sure it's a good idea to have more circular dependencies in the platform via TM4E. Ssuch an addition would force Java 17 BREE into the platform, which is yet another issue to consider carefully.

[laeubi]

Ssuch an addition would force Java 17 BREE into the platform, which is yet another issue to consider carefully.

Build is already Java 17, EPP is already Java 17, so having one bundle (we don't need to put the code into an exiting plugin) would not change much?

I'm not sure it's a good idea to have more circular dependencies in the platform via TM4E

@mickaelistria already mentioned one might be able to not use TM4E beside that, if we just have an org.eclipse.text.editorconfig bundle it should not be much of an issue...

[akurtakov]

Having circular dependency between tm4e and platform.releng build is a total no-go. Java 17 is not an issue for me (it's probably time to admit that Java 11 support other than producing Java 11 bytecode is of zero interest for my company team now).

[laeubi]

Having circular dependency between tm4e and platform.releng build is a total no-go

Maybe we have a different understanding of a "circular dependency" but for me a circular dependency is where A > B > A what can not be resolved, while here we have A > C < B what can be resolved...

Anyways @angelozerr can you explain where TM4E is used and if it can be either optional or replaced with other techniques?

[akurtakov]

Having circular dependency between tm4e and platform.releng build is a total no-go

Maybe we have a different understanding of a "circular dependency" but for me a circular dependency is where A > B > A what can not be resolved, while here we have A > C < B what can be resolved...

It's a releng "circular dependency" between p2 repos - platform -> tm4e -> platform

Anyways @angelozerr can you explain where TM4E is used and if it can be either optional or replaced with other techniques?

[vogella]

We have some circular dependencies already IIRC. The EMF edit plug-in IIRC.

[laeubi]

We have some circular dependencies already IIRC. The EMF edit plug-in IIRC.

The whole platform build is a "circular dependency" ;-)

Beside that, no one forces us to use the latest snapshot repository of TM4E ... we can simply use the latest release of TM4E, of course then might only use features of TM4E - 1 but this should not be an issue here...

[akurtakov]

Please, the fact that we have many issues doesn't mean we should add more! Let's agree to not make platform build worse than its current terrible state.

[akurtakov]

So to move the discussion in the right direction - TM4E is used for the editor of .editorconfig files which means that applying/supporting existing .editorconfig files can go in without the requirement on TM4E and I propose the discussion to go towards that goal. Having smart editor for .editorconfig files can stay separate.

[laeubi]

Even though I don't know how it works, but Eclipse sometimes recommend me to install things from the marketplace for "unknown" extensions.

So if we can integrate the .editorconfig itself, and link it to a market-place entry then it could be installed afterwards by a seperate project that support the editing of files.... @angelozerr would that be feasible for you?