-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[StickyScrolling] Introduce enhancement point #2756
base: master
Are you sure you want to change the base?
[StickyScrolling] Introduce enhancement point #2756
Conversation
In order to implement editor/language specific sticky lines provider, a new extension point is introduced.
@@ -15,7 +15,8 @@ Export-Package: | |||
org.eclipse.ui.internal.editors.text.codemining.annotation;x-internal:=true, | |||
org.eclipse.ui.internal.texteditor;x-internal:=true, | |||
org.eclipse.ui.internal.texteditor.stickyscroll;x-internal:=true, | |||
org.eclipse.ui.texteditor | |||
org.eclipse.ui.texteditor, | |||
org.eclipse.ui.texteditor.stickyscroll;x-internal:=true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so we would remove the "x-internal:=true" part to make this "real" API once we are confident enough?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that would be the idea. But I'm not sure if this is the right approach or if this is a good idea.
Can this share a lot of code with the folding range? |
In order to implement editor/language specific sticky lines provider, a new extension point is introduced.
See issues:
The idea is that the package of the extension point is internal in the first place.
If both implementation works as expected, the API is most probably stable and we can change to package of the extension point to public usage.