Sublime Forum

Indexing stops due to preferences being changed by something

#1

I’ve had several times recently where Sublime has just quit showing any Goto links when I hover over a function. I checked the Indexing Status menu item and found that the indexer was not running. I tried deleting the indexes and still the indexing refused to start.

Finally, I happened to check my user preferences, and found a line had been added to the bottom:

index_files: false,

I commented them out and left a message for myself

// "index_files": false,  // HOW DID THIS NONSENSE GET HERE?  NEVER, NEVER, NEVER!

Everything started working as expected. About a month later, indexing stopped again. I found this:

// "index_files": false,  // HOW DID THIS NONSENSE GET HERE?  NEVER, NEVER, NEVER!
index_files: false,

So I simply changed the value to true, and everything is working again.

What could possibly be changing these values?

Windows 10.0.19045 Build 19045
Sublime Single User License Stable Channel, Build 4169

Installed Packages:

image

0 Likes
#2

FWIW, Package Control used to have a bug that could result in this, but that was fixed a while ago: https://github.com/wbond/package_control/commit/1ab5c0edced2a8e61efd541f16adc14fc15cb6d1

0 Likes
#3

Sounds like it’s isn’t fixed though

@deathaxe

0 Likes
#4

Is package control automatically kept up to date? I haven’t upgraded it manually.

[update] Package control was

Updated Mon Mar 04, 2024
goto v4.0.5; packagecontrol.io

0 Likes
#5

That is the latest version. When is the last time this happened ?

0 Likes
#6

Two days ago

0 Likes
#7

Commented out settings such as // "index_files": false, are a result of deleting settings programatically. Package Control however only ever actively sets this setting false during package upgrade and true afterwards. It never deletes that setting.

This indicates something else interfering.

I have a ST with hundreds of plugins running with indexing enabled on Windows and haven’t seen indexing being permanently disabled recently, even not during Package Control upgrades.

0 Likes
#8

The only programmatic change was the addition of index_files: false,.

I was the one that commented it out.

Whatever inserted index_files: false, after the comment did not make any change other than the addition of the new line.

If I’m understanding the logic flow, is index_file: false being added upon Package Control update, and then updated to the previous value after the update?

If so, could the lack of the directive (in user preferences) before the upgrade be mistakenly interpreted as originally being index_file: false?

0 Likes
#9

Yes, the idea is to pause the indexer during package upgrades to avoid the indexer breaking existing index entries due to a syntax definition possibly not being available temporarily. It should only start once after all packages are updated and all syntax definitions are available again. That’s probably not so important when upgrading a single package, but may make a difference when multiple ones are involved.

mistakenly interpreted as originally being index_file: false ?

No. If it is not present, the default value true is used and that state is stored on disk to even survive a crash. If anything goes wrong, the original value should be restored at least upon next ST start. That’s also indicated by console messages like “Package Control: pausing indexer” and “Package Control: resuming indexer”.

If the index state was not restored other settings such as active theme or color scheme, wouldn’t as well. The latter ones would be obvious only if a theme is updated, which causes the default one to be set during upgrade to avoid graphical glitches or parsing error messages.

The only case I am aware of it having been failing in the past was a user using a sync or backup software, which tracked User package. It modified settings during upgrade and caused settings to be messed up.

0 Likes
#10

Thank you for the clarification.

So at this point, I’m left with these assumptions:

  1. Plug-ins have the ability to write to user preferences (To be candid, the idea of a plugin having write access sounds a bit risky to me…)
  2. Most likely cause of my issue is a misbehaving plug-in
  3. Solution is likely trial-and-error to find which one it is
  4. Package Control has already dealt with the issue and should be good

Is it OK in this forum to edit the original post to add a list of installed plug-ins?

0 Likes
#11

Yes. A list of plugins might help.

0 Likes