-
Notifications
You must be signed in to change notification settings - Fork 87
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
Java syntax colors and settings don't save #756
Comments
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 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. |
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:
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... |
Originally reported in Bug 486992 and more recently in eclipse-packaging/packages#54
When in dark theme (but perhaps other cases too based on comments) when unchecking Bold in
Keywords, excluding 'return'
it's not maintaining the bold font I set.@valmirserpa kindly made a screen recording in eclipse-packaging/packages#54 (comment) which I embed here as the original was not necessarily stored in a permanent location:
screen-capture.video-converter.com.1.mp4
The text was updated successfully, but these errors were encountered: