GNOME Bugzilla – Bug 352854
modelines should revert to pref values when a modeline part is removed
Last modified: 2019-03-23 20:52:11 UTC
Currently, if you remove a part from the modeline and save your document, the default value (the one you set in the prefs) is not applied back to the document. This is workaroundable by closing the document and reopening it, or by setting the modeline to the default value before deleting it, but it's an ugly workaround.
It should be quite easy to fix it... especially if you know the code ;)
Created attachment 71655 [details] [review] patch This patch fixes the bug by reading the missing bits from modeline from gconf.
Created attachment 71661 [details] [review] patch v2 This patch only reads the modeline parts that have been removed.
Fixed in the development version. The fix will be available in the next major release.
Why you didn't use the gedit-prefs-manager functions?
Because they were said to be private to gedit, and thus aren't binded into python.
Who said that? I don't think gedit_prefs_manager functions are private, they are the "official" way to get access to the gedit preferences. I think we should bind it in python.
> Who said that? I guess that would be me, even if I phrased the thing a bit differently: I know that prefs-manager functions are public and accessible from C plugins. Nonetheless until this one came up we had no real example of a py plugin needing to access the prefs: all similar issues were better resolved by directly querying the properties of the view/buffer etc. Beside prefs-manager is a functional interface and doesn't support notification, so we'll have a situation were plugins need GConf to manage their prefs, need GConf to get notification about prefs, yet they'd use the prefs-manager for reading some of the internal gedit prefs. Substantially up until now my take on the issue was more a "wait and see", that is do not bind the api and set it in stone, until some compelling reason came up. This was doubly true in 2.14 were our api plans were even less clear. For instance now we have gedit.commands and gedit.utils... I think it would be clearer to bind the prefs in a gedit.prefs module.
> Beside prefs-manager > is a functional interface and doesn't support notification, This is true and we should probably fix it in the future. > so we'll have a > situation were plugins need GConf to manage their prefs, need GConf to get > notification about prefs, yet they'd use the prefs-manager for reading some of > the internal gedit prefs. Using gedit_prefs_manager let us abstract from the underlying way of managing preferences (this will help if gedit will ever be ported on Windows). > I think it would be > clearer to bind the prefs in a gedit.prefs module. I agree. My opinions about this problem are: - we should avoid to directly use gconf in plugins when possible (i.e. to access gedit core preferences) - we should try to improve gedit_prefs_manager to support notification and to provide a simple API for accessing to plugins specific preferences - if using gconf cannot be avoided we should use the GEDIT_PREFS defines instead of the names of the keys.