I assume the issue here is that the CSS for dark theme is overriding the settings in the UI:

Based on your observation, I posted a patch which removed all the bold settings, but there are other settings in that file that a user could also tweak. I'm wondering if it should just specify colors.

If I understood correctly, or maybe I wasn't clear, I believe the solution is not to remove the ability to make text bold, but to fix and allow the user the possibility to choose whether to use bold text or not. But if that's not possible, I'll understand. Thanks.

What @jjohnstn's change does is remove the code that forces the text to be not-bold on restart. That means also by default the keywords won't change to non-bold when turning on dark mode.

I'm wondering if it should just specify colors.

I think so as a workaround - until (unless) the underlying issue of fixing CSS in this case can be resolved so that a user can override the CSS on non-colour attributes.

Alright, now I understand what he meant. Thanks!

@jonahgraham @valmirserpa I have revised the patch to remove all non-color settings. I never use dark theme so wouldn't notice if something was missing. It seems to work fine but could either of you try it out and comment if there is something you feel should be added back.

@jjohnstn I don't use bold theme as a matter of course - @vogella provided that initial theme so perhaps he is in a better position to comment.

I don't use bold theme as a matter of course

dark theme

@jjohnstn I will perform some tests and I will return with the results. Thanks

Hi there,

it's hard for me to believe this issue is actually about 10-years old todo from the CSS / platform team. 😮 If it helps, here are some remarks from my analysis so far:

This problem was firstly reported as Bug 443373 and then by 3 more duplicates, including aforementioned Bug 486992. From there, we can see it is not just Java syntax settings related, but a broader problem in the Eclipse ecosystem.

Apparently, the cause of the issue lies in the fact that persisting the user modified settings to the "*.prefs" file doesn't work well:

• it seems to incorrectly remove all boolean-like properties which are specified in the Dark theme's CSS file,
• it seems to work correctly for color properties.

So I guess that either the Dark Theme team does something wrong, or, more probably, there is something wrong in the core, namely in the eclipse-platform/eclipse-platform-ui project.

There are clues that the issue could be related, or even caused by how the "dynamic and internal" property "overriddenByCSS" is treated in the preferences engine.

Anyway, I wonder if just simply debugging the Eclipse shutdown procedure, while putting a breakpoint say somewhere to the EclipsePreferencesHelper for a start, could lead to finding the culprit. I guess if it would be so simple, some developer would already have done so...?

WORKAROUND: Finally, here is what I believe is a workaround for the issue (tested on my PC): If one uses the OOMPH preferences recorder, then all user modified settings from the Syntax Coloring page get successfully re-applied on another Eclipse start, even when they don't get properly persisted to the "*.prefs" file (because they are read from another file and recorded there, if not opted-out by the user).

Another interesting finding: changes seem to be correctly persisted even for the problematic boolean properties, when the settings get imported (via "File > Import > Preferences"). So it looks like there must be some trigger which causes the persistence to fail only when editing the settings manually...