Sublime Forum

How to get a specific-to-view's settings? — non-inherited

#1

I try to get an overview of a view’s settings.
But I only wants view’s specific settings. Not all inherit values.

Basic setup:

  • We have no rulers settings in Preferences.sublime-settings
  • We have rulers at [ 100 ] in Packages/User/Python.sublime-settings
  • The current view’s syntax is Python

At this point, if we check view.settings().get("rulers") we get the value defined in Packages/User/Python.sublime-settings as expected.

  • For the view, we set rulers at [ 120 ]. We specifically use menu/command to do it
    The view has its own/specific settings.
  • Same operation, but with [ 100 ], same as “default”.
  • Change the Packages/User/Python.sublime-settings for "rulers": [ 80 ]

At this point, we see/know that the view has still its rulers at [ 100 ], not as “default”.
→ ofc : we do not used view.settings().erase("rulers")

Note: Users that expect a “reset” for this operation, could tell “What the F… bug is this?” (^^)

Using view.settings().to_dict() also contains the “parent settings”
eg. from Packages/User/Python.sublime-settings

We can’t get the “source settings” of settings values. (ie. where is it from? Application, Syntax, Project settings?) — Is it a settings specific only to this view or not? 🤷

I could “compare all parents settings to view settings, and remove all keys that as the same values” and use this to get a “final view specific settings dict” but:

  1. I need to find all parents settings : which seems hard for some cases. Even if I could…
  2. as we saw above : a view’s specific settings could have the same value as a parent settings. Which will be “removed” to the “final view specific settings dict” (not intended).

So. Is there a workaround?

Or, should I request this as api feature? Will it be useful? or I just need to “deal with it”? x)

0 Likes
#2

The setting hierarchy for a view is fairly complex, and not all of the settings objects are exposed in the API; being able to tell if the view has a setting won’t necessarily help. Perhaps an API to get the origin of a setting would work better? Is this just for debugging purposes or do you have a different use case?

0 Likes
#3

A use case is provided in Default/ui.py, which does some hacks to determine whether color scheme is set view-specific or not.

MarkdownEditing’s color scheme selector also needs such kind of information to determine whether to set or delete a color_scheme value from view or syntax specific settings. It wants to be able to remove a view specific color_scheme for the global one to become affective.

An api to tell the source of a setting would be helpful in such scenarious.

Currently we can just query view’s settting an than manually attempt to get syntax-specific, project-specific and global settings to get a hint about settings’ source.

0 Likes