Community
Participate
Working Groups
Inlined line header annotation are drawn in the previous line spacing of the line. This line spacing is managed with the StyledTextLineSpacingProvider which works well but must require some improve. An another idea is to manage line header annotation like line content annotation with GlyphMetrics ascent. It will require to fix other problem like cursor line height, etc
(In reply to Angelo ZERR from comment #0) > Inlined line header annotation are drawn in the previous line spacing of > the line. This line spacing is managed with the > StyledTextLineSpacingProvider which works well but must require some improve. I also think that using LineSpacingProvider for this now seems semantically incorrect: the linespacingprovider create line space between the lines when they are wrapped or don't apply on 1st line. This is the good behaviour for line spacing in general (think about what LibreOffice does for which the linespacingprovider would be perfect) but really isn't suitable for lineheaders as codeminings use it. > An another idea is to manage line header annotation like line content > annotation with GlyphMetrics ascent. That's much more consistent and would greatly simplify code and reduce the number of entangled issues to consider for better codeminings. It's IMO a very good way forward (which could be made perfect with bug 531769). > It will require to fix other problem like cursor line height, etc If those problems are existing problems that surface now, then I think it's a good thing as it's a fight against technical debt. Please make sure you open different tickets for those.
New Gerrit change created: https://git.eclipse.org/r/118919
Here a gerrit patch with this idea https://git.eclipse.org/r/118919 but please note it's not perfect. There are severl problem with cusror, matching bracket and clipping. I will create bugs for each problem.
New Gerrit change created: https://git.eclipse.org/r/119283
Gerrit change https://git.eclipse.org/r/119283 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=2d294da598154bcd7ebf63fa4dc6ae8783304be5
(In reply to Eclipse Genie from comment #5) > Gerrit change https://git.eclipse.org/r/119283 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=2d294da598154bcd7ebf63fa4dc6ae8783304be5 > This has unapproved API changes after the freeze: http://download.eclipse.org/eclipse/downloads/drops4/I20180318-2000/apitools/freeze_report.html Either revert or request PMC approval for that.
Thanks Dani. I missed this one as the getLineSpacing method was somehow internal design. The initial issue is that we missed to add the @noreference tag. I'll ask PMC approval for this to be changed.
+1 from a PMC member, please give other PMC members are chance to cast their vote.
(In reply to Lars Vogel from comment #8) > +1 from a PMC member, please give other PMC members are chance to cast their > vote. You're good to go.
(In reply to Dani Megert from comment #9) > (In reply to Lars Vogel from comment #8) > > +1 from a PMC member, please give other PMC members are chance to cast their > > vote. > > You're good to go. Thanks guys and sorry for the disturbance!
Sorry guys with my big mistake to expose getLineSpacing in the InlinedAnnotationSupport. No I understand more why Eclipse code defines internal listener and not implement the root class with listener interface. Thank's again to Eclipse code for teaching me something else!
(In reply to Angelo ZERR from comment #11) > Sorry guys with my big mistake to expose getLineSpacing in the > InlinedAnnotationSupport. > > No I understand more why Eclipse code defines internal listener and not > implement the root class with listener interface. > > Thank's again to Eclipse code for teaching me something else! No worries master Angelo. If I could make such cool mistakes as you I would be very proud
