eclipse-platform
Provide .editorconfig support
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.
@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,
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.
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?
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
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.
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...
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).
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?
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 > Awhat can not be resolved, while here we haveA > C < Bwhat 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?
We have some circular dependencies already IIRC. The EMF edit plug-in IIRC.
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...
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.
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.
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?
Marketplace entry that has a tag fileextension_editorconfig should be everything needed for MPC to suggest installing the editor.
Dont worry I can remove TM4E which provides syntax coloration and some features with langage configuration wich provides machine bracket for .editorconfig file but the other factures like validation codemining complerion for .editorconfig is not linked to TM4E.
The only required dépendance is ec4j which is on maven central.
Keep in mind the apply of .editorconfig works correctly with only generic editor and not with some editor like jdt java editor.
More I need to use java reflection to add a custom IPreferenceStore to generic editor which is not very clean.
To be clean generic editor should provide perhaps an extension point to add an ipreferencestore
For .editorconfig syntax coloration I think TM4E should provide the textmate for .editorconfig file.
I have just one question for ec4j dependency, can I create a PR with plusieurs which have à lib folder which contains ec4j jar?
We could manage that properly in an another PR? What do you think about that?
It's fine to have first draft with ec4j being internal dependency. Before accepting we should have it added to the target platform referring to the maven artifact directly.
I have just one question for ec4j dependency, can I create a PR with plusieurs which have à lib folder which contains ec4j jar?
You can add maven dependencies directly to the target and use is like any regular bundle, so no need for workaround like lib folders!
I have created a draft PR at https://github.com/eclipse-platform/eclipse.platform.text/pull/89 without TM4E but we need to do some PR before, see https://github.com/eclipse-platform/eclipse.platform.text/pull/89#issuecomment-1250040908
Imho having .editorconfig support consists of several things.
The first level is parsing the file and applying the correct settings from it to the editor.
The next step is acting on those preferences: while I think the indent_style and indent_size do map on existing, workspace-level settings (that are currently already taken into account in most of not all editors), settings like trim_trailing_whitespace and insert_final_newline do not (to my knowledge). These settings exist for the JDT Java editor, but aren't generic, workspace-wide settings available to/implemented in all editors.
I for one would expect that if Eclipse would support .editorconfig, it would also mean that all the settings one can set via .editorconfig would also be supported in all editors (although personally I'd be ok with just support in the generic editor)
Third level would be rich editing support for .editorconfig files
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?
Per definition, .editorconfig overrides workspace- and project-level settings: it defines settings on a per-fileType basis, looking for the closets applicable settings by looking for the closets .editorconfig file (containing relevant settings) from the current filled location up through its parent directory structure, until either matching settings have been found or a .editorconfig file is encountered that has root = true
for one would expect that if Eclipse would support .editorconfig, it would also mean that all the settings one can set via .editorconfig would also be supported in all editors
Given that Eclipse is extensible "all" might never be achievable ... so starting with "one" that is recommended to be used for new editors seems suitable to me.
I for one would expect that if Eclipse would support .editorconfig, it would also mean that all the settings one can set via .editorconfig would also be supported in all editors (although personally I'd be ok with just support in the generic editor)
Given that Eclipse is extensible "all" might never be achievable ... so starting with "one" that is recommended to be used for new editors seems suitable to me.
It is an important question, should .editorconfig works with any editor or with just genereic editor? The answer will determine where the extension point which create and add an IPreferenceStore into the editor (in texteditor extension point or in genereric extension point).
Just assume I have an editor that supports Grahical editing of a binary file format, has "trim_trailing_whitespace" any meaning?
By the way, as far as I know no one prevents others to also looking at the generic editor extension point later on...
Again, it is the .editorconfig which should have the priority. But any improvement are possible.
whatever takes precedence should be shown in the properties file of any resource:
- the effective used file
- the effective setting
whatever takes precedence should be shown in the properties file of any resource:
I don't think that this is mandatory, any editor can ignore these defaults these are just resources settings. Still it would be useful if there would be an extension point to inform the user about that these settings are overridden somewhere else.
I agree with your all comments, but to be honnest with you I could not do that in the same PR and I'm not sure that I will have time to implement all of your ideas. My main goal is to provide .editorconfig basicly and after we could improve it step by step.