Community
Participate
Working Groups
IMHO, line header codemining should be in italic. I think it's a good choice because in JDT Java Editor, mining and Java annotation (ex: "@Override") are renderered with same style. For the moment it's hard coded, but in the future mining renderer should be customized with preferences "Colors and Fonts". I'm waiting for https://bugs.eclipse.org/bugs/show_bug.cgi?id=532326 to create a gerrit patch
I believe we need something more generic and configurable. The font (which font, the size, italic or not...) should be something that comes from the FontRegistry and that users could customize in color and font preference page.
New Gerrit change created: https://git.eclipse.org/r/119257
AFAIK typically fonts are defined via the themes extension point. See http://blog.eclipse-tips.com/2008/08/adding-color-and-font-preferences.html But I don't think we can use this in org.eclipse.jface.text as it would introduce as it would create a dependency to platform.ui. @Mickael, what is the correct process to define fonts in the eclipse.text repo?
Isn't the font to be used something that is language-specific? Who says that minings should be displayed identically in JDT and in PDT editors, for example? Or in markup editors?
(In reply to Thomas Wolf from comment #4) > Isn't the font to be used something that is language-specific? Who says that > minings should be displayed identically in JDT and in PDT editors, for > example? Or in markup editors? Currently, it is the same for all and hard-coded. I believe this bug is about solving the hard-coded part.
(In reply to Lars Vogel from comment #3) > But I don't think we can use this in org.eclipse.jface.text as it would > introduce as it would create a dependency to platform.ui. org.eclipse.ui.workbench.texteditor which defines the code mining extension point and API already has extensions to org.eclipse.ui.themes. So no problem here. > Isn't the font to be used something that is language-specific? So far, there is no real user-story to support this. > Who says that minings should be displayed identically in JDT and in PDT editors, for example? Or in markup editors? I think it's an implementation choice. So far, I don't think you'll manage to convince current codeminings contributors to work on language-specific font for codeminings. I, for example, think about a totally opposite way: it's better to keep a single preference for consistency, and editors that don't want to be consistent with the IDE shouldn't use this extension point. And so far, there is no strong need for this feature so most will probably prefer working on more profitable tasks. That said, if you feel like you need to contribute such customization in the code minings, that would be welcome. There is no political opposition against more customization, it's more about priority management and keeping things simple.
(In reply to Mickael Istria from comment #6) > (In reply to Lars Vogel from comment #3) > > But I don't think we can use this in org.eclipse.jface.text as it would > > introduce as it would create a dependency to platform.ui. > > org.eclipse.ui.workbench.texteditor which defines the code mining extension > point and API already has extensions to org.eclipse.ui.themes. So no problem > here. Nice. Gerrit upcoming shortly.
New Gerrit change created: https://git.eclipse.org/r/125390
(In reply to Eclipse Genie from comment #8) > New Gerrit change created: https://git.eclipse.org/r/125390 Patch does not yet react to changes in the default font. Any example how this can be done? Without this, this patch does more harm than it helps as code minings will use fixed sizes even if the text font changes.
> Patch does not yet react to changes in the default font. It was one reason why I have not customized font:) > Without this, this patch does more harm than it helps as code minings will use fixed sizes even if the text font changes. I suggest you to see and understand code from AbstractTextZoomHandler#execute. It should be very cool if you could manage this zoom feature.
(In reply to Angelo ZERR from comment #10) > I suggest you to see and understand code from > AbstractTextZoomHandler#execute. It should be very cool if you could manage > this zoom feature. The AbstractTextZoomHandler#execute will only adjust values which have a common base font and have either no font data set or the same as the referred base value. So if I set the code mining to org.eclipse.jface.textfont and never change it from the base font, it will also increase. Mickael (as Mickael did the implementation of this handler), was there a particular design decision behind this logic? Why not increase all fonts with the same parent independent of their current value?
(In reply to Lars Vogel from comment #11) > Why not increase all fonts > with the same parent independent of their current value? The initial idea was that if font were different (espacially size) then user probably don't need to change both fonts actually. So zooming in/out was assumed to be only desired on the current font and similar (ie same "family" with a common ancestor and same value). But I'm not against a change in this if a better strategy is decided. For example, a better approach could be instead of comparing th the FontData in AbstractTextZoomHandler, to look inside the FontData and compare the sizes. So 2 fonts with same size and different size would be linked.
If we are not able to use the FontRegistry right now, would it make sense to change the hardcoded font for codemining to italic as a 1st iteration? Just like stage instructions in theater, italic is often used for non-payload content in several domains.
(In reply to Mickael Istria from comment #13) > If we are not able to use the FontRegistry right now, would it make sense to > change the hardcoded font for codemining to italic as a 1st iteration? > Just like stage instructions in theater, italic is often used for > non-payload content in several domains. +1, lets merge Angelos https://git.eclipse.org/r/#/c/119257/
New Gerrit change created: https://git.eclipse.org/r/164462
Regarding comment 12 - I believe the zooming behavior is fundamentally broken. For example, zooming a Java editor by default results in the Git commit message and the console (along with 14 other items in my current Eclipse instance) also zooming in, even though these things are tangentially related at best. Additionally, if one overrides the Java editor font setting, and then zooms, only the Java editor and the Java compare view will update, and one might be surprised, having observed the previous behavior, to find that nothing else has updated. I realize that there is no way to use the font registry as it exists today to truly define what should and should not be modified, so, as it is, I propose that the behavior described above without overriding any fonts should be the behavior all the time. In other words, if one zooms a window somehow related to "Text Font", then all other fonts related to "Text Font" should zoom, regardless of any user overrides. If we can accept this, then we can resolve this bug. I have prepared a patch that allows for individually setting the font and colors of the Headline and Inline code minings, and also adjusts the AbstractTextZoomHandler to behave as described. See gerrit in #15.
(In reply to John Taylor from comment #16) > I realize that there is no way to use the font registry as it exists today > to truly define what should and should not be modified, so, as it is, I > propose that the behavior described above without overriding any fonts > should be the behavior all the time. In other words, if one zooms a window > somehow related to "Text Font", then all other fonts related to "Text Font" > should zoom, regardless of any user overrides. That can be slightly better, however, please open a dedicated bug with this proposal and mark it as "see also" or "depends on" for this current bug.
Hi, I just came across this bug after trying to figure out how to change the font for code minings. I see that the dependent bugs are all resolved now, is there any chance of getting this merged? Thanks
