Community
Participate
Working Groups
Build Identifier: 20110301-1815 Open an Xtext grammar. The comments have a default color (on my machine seems to be green). In the preference page, change the color to something else and press OK, OK. The color actually changes in the editor (that's fine). Then open the preference page again and change the color to black (that's the upper left square on my color palette). Push OK, OK. Nothing happens in the editor. Reproducible: Always
I'm using 2.0 M6
This one depends on bug 306352 and it seems that we cannot do much about it. Is it possible to set comment color black in the Java Editor?
(In reply to comment #2) > This one depends on bug 306352 and it seems that we cannot do much about it. Is > it possible to set comment color black in the Java Editor? Yes, seems to work fine in the Java editor (tried for multi-line comments). Also tried "restore to defaults" and it goes back to a boring green as expected.
Preliminary scheduled for 2.0RC1
Created attachment 195386 [details] proposed patch pls review and test whats missing: integration with XtextEditor#affectsTextPresentation to immed. change the editor presentation. requires a shared preferencestore in IPreferenceStoreAccess.
Hi Michael, thanks for the patch. Unfortunately it looks to complicated to me - at least at a first glance. Furthermore, there have been other changes which affect the preference access / store mechanism. Jan is currently digging into this topic. Regards, Sebastian
as mentioned in some comment here jdts java editor can set the comment color back to black i have investigated their solution (which is based on some intermediate preferencestore i.e. OverlayPreferenceStore) and ported it to Xtext to match the existing preferencestore handling in AbstractDetailsPart trying to minimize changes. the (still existing) issue with the missing editor presentation integration should be handled in a separate bug. (In reply to comment #6) > Hi Michael, > > thanks for the patch. Unfortunately it looks to complicated to me - at least at > a first glance. Furthermore, there have been other changes which affect the > preference access / store mechanism. Jan is currently digging into this topic. > > Regards, > Sebastian
We fixed our preference store setup to get all changes propagated correctly. There was also a bug in the handling of defaults in the AbstractDetailsPart. Seems to work fine now. Pushed to master.
Closing all bugs that were set to RESOLVED before Neon.0