Repository navigation
Uninstalled linter packages stay registered in persist.linter_classes and keep linting until restart #1998
Description
After uninstalling a linter plugin (for example SublimeLinter-eslint) through Package Control, its linter class stays registered in persist.linter_classes and keeps linting every matching view until Sublime Text is restarted.
Repro (Sublime Text 4215 on Windows, Python 3.14 host, SublimeLinter from Package Control, SublimeLinter-eslint installed with eslint in a project node_modules):
- Open a
.jsfile in that project; eslint results appear. - Remove the linter package with Package Control ("Remove Package" > SublimeLinter-eslint). Package Control reports the removal as done and the
.sublime-packagefile is deleted; the console printsunloading plugin SublimeLinter-eslint.linter. - Open another
.jsfile in the project.
Expected: no eslint results, the linter is gone.
Actual: the new view is still linted by eslint. In the console of the same session:
>>> from SublimeLinter.lint import persist
>>> sorted(persist.linter_classes)
['csslint', 'eslint', 'jshint', 'php'] # all four linter packages had already been removedI saw the same thing when a package file was deleted directly (jshint, php, csslint) and when using Package Control's remove_package() (eslint): the class object of the removed package is still in persist.linter_classes and still assigned to buffers, and the linter binary is still executed.
Cause: linter.register_linter() does persist.linter_classes[name] = cls, and nothing removes the entry when the plugin module is unloaded. persist.py has no unregister function.
Suggested fix: drop entries from persist.linter_classes whose module is no longer loaded (in plugin_unloaded of the wrapper via a hook, or by checking cls.__module__ in sys.modules in assign_linters_to_buffer), and clear their errors from the store.
Activity
kaste commentedon Sep 29, 2026
Ack, this is a long- (ever-) standing issue. Unsure about the best fix.
kaste commentedon Sep 29, 2026
Actually, https://packages.sublimetext.io/packages/SublimeLinter-addon-toggler implements part of this by watching the settings/Preferences. That would mean a separate plugin on the root just for this feature; pulling the toggler code and extending it with the use case here.
dpc00 commentedon Sep 29, 2026
FWIW I opened a small PR for this, #1999:
electdrops linters whose plugin module is no longer insys.modules. Since Sublime pops the module when it unloads the plugin, this needs no extra plugin and no cooperation from the linter packages, and it works no matter how the package went away (removed, disabled, file deleted). Happy to rework it if you would rather go the toggler route.kaste commentedon Sep 29, 2026
The toggler runs once, as response/reaction to an event, and can call
sublime_linter_config_changedwhich is semantically the right thing to do. Calling that while actually being in a "lint"-process seems more convoluted or brittle.dpc00 commentedon Sep 29, 2026
Agreed on the design, thanks. I reworked #1999 that way: it now observes
ignored_packagesand Package Control's settings, and after a change forgets the linters of disabled or unloaded plugins and callssublime_linter_config_changedonce. Nothing runs in the lint path any more. I checked it live by removing SublimeLinter-json through Package Control: the linter was gone and the open view lost its errors without a restart.