Disable-able Syntax Highlighting Preference

[lobre]

Hey,

I have tried to answer my self-created issue:

#1659

As a sum-up, I have added a new syntax-highlighting GSettings key plus a toggle under Preferences -> Interface so users who prefer monochrome editing can disable highlighting globally while leaving the existing language picker active for commenting, Markdown shortcuts, etc.

The SourceView simply toggles Gtk.SourceBuffer.highlight_syntax, so search hits and other non-language effects keep working, and the language dropdown now says "Document language" to better reflect its broader role.

Happy to adjust any of this if you think there is a better way to expose the preference, or if there is anything with the implementation.

[lobre]

Also, I see that the build fails, but I am not sure if it has anything to do with my changes.

[jeremypw]

Funnily enough I just started work on this. I have pushed work for info. Your PR looks more elegant but does it listen to changes in the setting?

[jeremypw]

There seems to be an issue with Flatpak CI. Not sure why - it doesn't seem to be associated with the project code though. I can build a Flatpak OK locally so I am ignoring it for now.

[jeremypw]

I'll let you complete your PR as you started first and look like you're on the right lines.

[lobre]

I guess it is all I have :)

It already picks up live preference changes.

See src/Widgets/SourceView.vala:129-130:

restore_settings ();
settings.changed.connect (restore_settings);

So, restore_settings seems to reapply all editor settings to the view. The first line calls it once, so the brand-new buffer adopts the current preferences. The second line is connecting the changed signal from settings to that same method, so every time any GSettings key under /io/elementary/code/settings/ changes, restore_settings() runs again.

I have tested the implementation on my current build, and it works for me.

[jeremypw]

@lobre You are right. The problem with this function I've noticed is that all the settings are restored when any one of them changes. Also there are several places around the code base where different classes monitor specific settings which this function also monitors so things get called twice. I think that for this PR we can leave things as they are but we probably need to have a review of settings handling at some point. It would seem restore settings () should only be called when there is a need to refresh all the settings (if there is one) while different widgets should handle specific settings that affect them. That can be left for another PR though.

[jeremypw]

Works as expected - lets go!

[lobre]

I think that for this PR we can leave things as they are but we probably need to have a review of settings handling at some point.

Makes sense effectively, thank you again for the merge!