Community
Participate
Working Groups
https://bugs.eclipse.org/bugs/show_bug.cgi?id=529011 Has feature request to add inline annotations for function parameters. It would be great to add ability to create inline annotation via markers. so you can just create a marker and set additional attributes that will make it either header or inline and provide text to be shown as marker already has most of the required attributes. This will improve inline markers usage as no extra reconcilers will be required .
Note that markers are associated to a file, are not specific to an editor, and do trigger events when created. So if you want to go towards usage of markers, it means that the annotation would be visible and all editors that have support for code mining. What additional value do you think markers would bring to the CodeMining API which a focused CodeMining provider wouldn't?
I'm thinking of simplifying creation of text annotations creation. Agree that it will be visible to all editors. But this can bring support of new marker types where plugin developer can add marker with some help inline. Or even writing generic plugins not related to editor that will provide small features like color samples in https://www.eclipse.org/eclipse/news/4.8/M5/#codemining-extension-point.
(In reply to Roman Parashchyn from comment #2) > I'm thinking of simplifying creation of text annotations creation. Have you tried the API? So far, I don't have the impression it does require much simplification. What use-case did you try that you think would be easier with markers? > Or even writing generic plugins not related to editor that will provide > small features like color samples in > https://www.eclipse.org/eclipse/news/4.8/M5/#codemining-extension-point. Note that this color preview in the example here is NOT a code mining per se, but a TextAnnotation which involves a specific drawing strategy. A marker couldn't easily provide such a specific drawing strategy.
Isn't it a dup of bug 540443 ?
While the overall idea is interesting, bug 540443 shows that similar things are already achievable with little code (hence introducing new API may not be worth the cost) and there is no concrete user-story supporting it at the moment. Reducing priority.
