Skip to content
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

Fix the prefer_standard setting #1

Merged
merged 3 commits into from
Dec 18, 2024
Merged

Fix the prefer_standard setting #1

merged 3 commits into from
Dec 18, 2024

Conversation

bandcampben
Copy link

@bandcampben bandcampben commented Dec 13, 2024

The standardrb plugin for SublimeLinter has a nifty linter setting called prefer_standard, that will choose to use standardrb or rubocop based on the presence of a standardrb.yml file. It’s very useful when switching between trackpipe and services, and between newer standardrbised services and older ones.

But it doesn’t work. It tries to get the SublimeLinter settings in a way that doesn’t seem to be supported any more:

view.settings().get('SublimeLinter.linters.rubocop.disable')

I dug around and figured out that we can get the SublimeLinter settings like so instead:

sublime.load_settings('SublimeLinter.sublime-settings')

The docs suggest that load_settings does some cacheing, and it doesn’t seem to affect performance at all in my testing (this whole function is run in a background thread anyway).

I have no idea how Python formatting is supposed to look (ironically), so I’m mostly looking for a basic review of the Python. If it works for us I might submit a PR and try get the fix into the ST package manager.

Use `load_settings` to access SublimeLinter plugin settings that are no longer
available from the View.
Copy link

@bc-kevinm bc-kevinm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like valid python to me!

Copy link

@bc-kevinm bc-kevinm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BUT! I think Dict.get() will return None if the key does not exist in the dictionary so this will cause a AttributeError if we get None from, say, linter_settings.get('rubocop') and no rubocop settings exist.

So I think we need to defend against None. I think the easiest way is to supply a second default result parameter to Dict.get:

>>> aa = {'a': 1}
>>> aa.get('a')
1
>>> aa.get('b')
>>> aa.get('b').get('c')
Traceback (most recent call last):
  File "<python-input-5>", line 1, in <module>
    aa.get('b').get('c')
    ^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get'
>>> aa.get('b',{}).get('c')
>>>

@bandcampben bandcampben merged commit 1ca778f into main Dec 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants